On 03/10/2016 05:37 AM, Ian Abbott wrote:

As a Brit, I must admit I was confused by this patch!

Hello Ian, I think the more important question is: are you confused when running tzselect after applying the patch? Given the existing choices in top level menu, where would you look for UTC? I think the prime meridian... London/Greenwich. That would be my first look.

On 03/10/2016 05:21 PM, Clive D.W. Feather wrote:

J William Piggott said:

...

Given the existing choices in top level menu, where would you look for UTC? I think the prime meridian... London/Greenwich. That would be my first look.

But UTC is not the time at Greenwich. They happen to be the same right now (give or take a second or so) but won't be in a few weeks.

How does 'where would you look' turn into 'the same as'?

I think Etc/ is the right place for this; it's a special case zone rather than a geographical one.

Do you mean as a top level menu entry for tzselect, or in regard to the etcetera source file? If its the later, I question it due to the Theory file saying etcetera can be excluded. That would leave the database without a UTC file.

On 03/10/2016 05:22 PM, Guy Harris wrote:

On Mar 10, 2016, at 2:04 PM, J William Piggott <elseifthen@gmx.com> wrote:

...

Given the existing choices in top level menu, where would you look for UTC? I think the prime meridian... London/Greenwich. That would be my first look.

I'm about 8000 km from the Prime Meridian, and it's now 2016-03-10 22:21 UTC here - just as it is where everybody else on the list is.

I'm about 10840 km from Tokyo, and it's now Sun Mar 13 09:54:15 JST 2016 here - just as it is where everybody else on the list is.

*I'd* look for UTC as something completely unconnected to any continent on Earth; as Paul indicates, that's what the "Universal" in "Coordinated Universal Time" means.

That's not what "Universal" in UTC means. It means it is used as a universal reference, not that it has no geographic origin. If UTC has no geographic origin the entire time zone system breaks down. Any latitude could have been chosen as the universal reference, that wouldn't make its geographic origin disappear. What is your solution? How should the UTC _file_ be cataloged in the zone tables? What coordinates should the entry have? What CC should be used? The answers are obvious once you recognize that UTC does have a geographic origin.

On Mar 12, 2016, at 5:00 PM, J William Piggott <elseifthen@gmx.com> wrote:

Any latitude could have been chosen as the universal reference, that wouldn't make its geographic origin disappear.

But that means that the particular longitude chosen as the universal reference has no Deep Significance.

What is your solution? How should the UTC _file_ be cataloged in the zone tables?

At the top level, not under any continent, or even under Etc.

What coordinates should the entry have?

None. It's not intended to be local time for a particular location.

What CC should be used?

None.

The answers are obvious once you recognize that UTC does have a geographic origin.

I recognize that UTC: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pd... happens to be a time offset from TAI by a number of seconds "to ensure approximate agreement with UT1", and that UT1 is "{the mean solar time of the prime meridian obtained from direct astronomical observation} corrected for the effects of small movements of the Earth relative to the axis of rotation (polar variation)". I do *NOT* recognize that it is a form of European time, and therefore should have the continent of Europe associated with it; for one thing, the prime meridian cuts through Africa as well.

On 10/03/16 22:04, J William Piggott wrote:

Given the existing choices in top level menu, where would you look for UTC? I think the prime meridian... London/Greenwich. That would be my first look.

All my systems have two options ... UTC or Local Time. UTC is certainly not the same as London Local Time and I expect any well designed system to be running UTC at the server level, and then allow the client to view that direct, or in an alternate Local offset, which need not be their own local timezone. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

On 13/03/16 01:01, J William Piggott wrote:

...

...

Given the existing choices in top level menu, where would you look for

...

...

UTC? I think the prime meridian... London/Greenwich. That would be my first look.

UTC is certainly not the same as London Local Time How does 'where would you look' turn into 'the same as'?

I think the general consensus seems to agree that if one is using UTC it is NOT because you are looking for anything to do with a location. And as has been pointed out, Windows does not have an easy way to switch between UTC and 'local time'. As indicated previously, my reason for being here is to ensure that material normalised to UTC time can be accurately mapped back to the local time, so in my book UTC will always be a generic setting. What messes things up is exactly how the computer handles 'UTC' with relation to leap seconds and so even 'UTC' has to be augmented by some flag which handles those differences :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

J William Piggott said:

Try tzselect with the patch applied. I think you will see it is not so bad. Given the existing choices in top level menu, where would you look for UTC?

My answer to that question is based on personal experience. My GPS has a World Clock application and the zone selector is geographically based, just like tzselect. I followed the menus straight to London. As with tzselect, no choice for UTC was offered. I had to settle for Reykjavik.

That would be because the London time zone is not the same as UTC, though Reykjavik is. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

export TZ=UTC has always worked. With regards to GMT != UTC I think we have the situation globally that legal time is based on astronomical time but we all set our clocks by atomic time. So Europe/London is in theory GMT in the winter and GMT+1 = British Summer Time in the summer but we set our clocks to UTC in the winter and UTC+1 in the summer and no-one cares about the difference until we have to implement a leap second. Julian On 11/03/2016 09:19, "tz-bounces@iana.org on behalf of Goudge, Stephen" <tz-bounces@iana.org on behalf of stephen.goudge@petards.com> wrote:

Clive D.W. Feather said:

...

J William Piggott said:

...

Try tzselect with the patch applied. I think you will see it is not so bad. Given the existing choices in top level menu, where would you look for UTC?

My answer to that question is based on personal experience. My GPS has a World Clock application and the zone selector is geographically based, just like tzselect. I followed the menus straight to London. As with tzselect, no choice for UTC was offered. I had to settle for Reykjavik.

That would be because the London time zone is not the same as UTC, though Reykjavik is.

Regarding personal experience using GPS handhelds and GPS-enabled cameras etc: I've long ago accepted that you just shrug and select Reykjavik if you want to have UTC. Even if these devices (the small selection I happen to use) *did* offer UTC directly, I wouldn't expect to find it listed next to London.

Regards, Stephen Goudge Senior Software Engineer

390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU

T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com

__________________________________________________________________________ _________________

This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud __________________________________________________________________________ _________________

This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful.

Petards Group plc is registered in England & Wales. Company No. 2990100 __________________________________________________________________________ _________________

----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. -----------------------------

On Mar 12, 2016, at 5:02 PM, J William Piggott <elseifthen@gmx.com> wrote:

Where would you expect to find it in a geographically arranged catalog? The only answer is the prime meridian, the same page London would be on.

An alternative is not to have the catalog 100% geographically-arranged, and offer UTC as an alternative to the geographical locations.

J William Piggott said: [UTC]

...

... I wouldn't expect to find it listed next to London. Where would you expect to find it in a geographically arranged catalog?

I wouldn't. You're deliberately limiting the possibilities and then trying to force an answer (which is wrong anyway; even if you accept UTC = prime meridian, it goes through countries other than the UK). The correct answer is to class it as non-geographical. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Apparently DST was important to the United Cigar Stores Company: http://cdn.loc.gov/service/pnp/cph/3g00000/3g08000/3g08100/3g08124v.jpg https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Victory-Cigar-Cong... Apologies if these have already been shared. Steve Jones OnTimeZone.com

On 03/10/2016 02:04 PM, J William Piggott wrote:

Should there be a zone table (tzselect) entry for UTC?

One can use tzselect to choose UTC already, no? Something like the following. $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) TZ - I want to specify the time zone using the Posix TZ format. #? 11 Please enter the desired value of the TZ environment variable. For example, GST-10 is a zone named GST that is 10 hours ahead (east) of UTC. UTC0 The following information has been given: TZ='UTC0' Therefore TZ='UTC0' will be used. Selected time is now: Thu Mar 10 23:19:59 UTC 2016. Universal Time is now: Thu Mar 10 23:19:59 UTC 2016. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='UTC0'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the ./tzselect command in shell scripts: UTC0

On 03/10/2016 06:21 PM, Paul Eggert wrote:

On 03/10/2016 02:04 PM, J William Piggott wrote:

...

Should there be a zone table (tzselect) entry for UTC?

One can use tzselect to choose UTC already, no? Something like the following.

You cannot set /etc/localtime to a posix TZ string. The Theory file says that tzselect, and applications like it that use the zone tables, are to assist a layperson it selecting a time zone _file_ from the database of _files_. IMO, a posix TZ string validator doesn't even belong in tzselect. Let me try to express this issue in another way. The Time Zone Database it made up of binary zone files. If I write the name of each file on a paper index card and say put these cards in geographical order in a drawer labeled zone.tab. Where would the UTC card be? The consensus seems to be, the UTC index card cannot be placed in the zone.tab drawer. It must go in a separate drawer all by itself, because it has no geographic identity. Civil agreements to use UTC as a 'universal' reference so that globally connected systems can function efficiently does not nullify the geographic origin of UTC. A geographical model with time zones defined as offsets from UTC requires UTC to have a geographic origin. https://upload.wikimedia.org/wikipedia/commons/e/e8/Standard_World_Time_Zone... The above link is a graphic representation of such a model. Read the text at the bottom center. Look at the offsets and times along the bottom. UTC is defined by the prime meridian and it runs smack through London, because the RGO is UTC's geographic origin. The zone tables are a text representations of the same model and the location of UTC is the same. If a user enters the coords +50+00, having the UTC _file_ presented as one of the _file_ choices is good. When tzselect is run the first choices are: Please select a continent, ocean, "coord", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) TZ - I want to specify the time zone using the Posix TZ format. If you were offered a million dollars to guess which category holds the UTC _file_, what would you pick? Pacific Ocean? Asia? I think users searching for UTC know enough about it to associate it with GMT, and GMT with Greenwich, and Greenwich with London/Britain. Europe would be the million dollar guess. Perhaps the issue everyone is having with my patch is the zone table comment which tzselect would display as: Please select one of the following time zone regions. 1) Britain (most areas) 2) Britain (Greenwich/GMT/UTC) Maybe something like this would work: Please select one of the following time zone regions. 1) Britain 2) UTC - the prime meridian If not here, then where? Or is your position unchanged that the database doesn't need a UTC file?

On Sat, 12 Mar 2016, Guy Harris wrote:

Then it should be fixed to offer:

Please select a continent, ocean, "coord", "UTC", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) UTC - I want to specify the use of Coordinated Universal Time. 12) TZ - I want to specify the time zone using the Posix TZ format.

Exactly! +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+

On 11 March 2016 at 07:26, Derick Rethans <tz@derickrethans.nl> wrote:

I think it would be nice if there was a top-level entry for that in tzselect, but it should definitely not be linked to London, or Greenwich, GMT, or anything like that.

I agree that this seems to be a bit of an oversight. On 12 March 2016 at 20:25, Guy Harris <guy@alum.mit.edu> wrote:

Then it should be fixed to offer: ... 11) UTC - I want to specify the use of Coordinated Universal Time. 12) TZ - I want to specify the time zone using the Posix TZ format.

I think this is a reasonable approach. I would point out that, per https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table, country codes AA, Q[M-Z], X[A-Z], and ZZ are permitted for "user assignment". If we were to absolutely feel that Etc/UTC needed a place in zone{,1970}.tab, it would belong there, *not* in GB. But I don't think that's necessary. -- Tim Parenti

J William Piggott wrote:

https://upload.wikimedia.org/wikipedia/commons/e/e8/Standard_World_Time_Zone... ... The zone tables are a text representations of the same model

Actually, they're closer to this: https://commons.wikimedia.org/wiki/File:Tz_world_mp-color.svg although this isn't quite right either, e.g., for Ürümqi.

You cannot set /etc/localtime to a posix TZ string.

You can remove /etc/localtime, giving UTC in all implementations I know of. We could approximate this by having a new top-level selection for tzselect which acts like TZ='UTC0'. Although that wouldn't be quite the same thing, it might be good enough.