On merging timezones - a radical proposal.
Or, more precisely, on the subject evicting redundant timezones from the user selection menu, since of course all current names will continue to exist as links if nothing else. I've thought about this some more, and I don't think it goes far enough. A user installing a new system doesn't _care_ about (my own proper time zone) America/Indianapolis, they don't have any need to accurately convert times from before _2006_ let alone 1970. Most users could probably be served just as well with America/New_York. I think it would be useful - particularly if we're abandoning being able to narrow it down by country - to define a heavily cut down set of "basic" time zones, that define each set of rules that exists _now_ without care for maintaining the past back to 1970, and then offer an "advanced" option for the rest. -- Random832
On May 22, 2013, at 11:27 AM, random832@fastmail.us wrote:
Or, more precisely, on the subject evicting redundant timezones from the user selection menu, since of course all current names will continue to exist as links if nothing else.
I've thought about this some more, and I don't think it goes far enough. A user installing a new system doesn't _care_ about (my own proper time zone) America/Indianapolis, they don't have any need to accurately convert times from before _2006_ let alone 1970. Most users could probably be served just as well with America/New_York.
I think it would be useful - particularly if we're abandoning being able to narrow it down by country - to define a heavily cut down set of "basic" time zones, that define each set of rules that exists _now_ without care for maintaining the past back to 1970, and then offer an "advanced" option for the rest.
"The rest" would probably include most if not all UN*X systems: http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html does not contain the string 2006 anywhere in it, so I view it as making an implicit promise that localtime() can convert any value of "seconds since the Epoch" to local time, and I wouldn't assume that there are no applications that depend on that working for older dates (and that matter and will cause loud complaints by users and/or independent software vendors that version $VERSION of $UN*X broke things).
On Wed, May 22, 2013, at 14:55, Guy Harris wrote:
"The rest" would probably include most if not all UN*X systems:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html
does not contain the string 2006 anywhere in it, so I view it as making an implicit promise that localtime() can convert any value of "seconds since the Epoch" to local time
Those go back to 1907, and that's on 32-bit systems. The thing is, most users won't actually _have_ files whose timestamps they care about to-the-hour accuracy in displaying their timestamps in local time. And those who do can pick advanced. We already don't handle (to make up an arbitrary example) people who moved from New York to Phoenix in 1992, but spent a month-long vacation in Florida in 2004. Since you can't define zones in terms of other zones, we don't even make it easy for them to handle themselves. -- Random832
On May 22, 2013, at 12:12 PM, random832@fastmail.us wrote:
On Wed, May 22, 2013, at 14:55, Guy Harris wrote:
"The rest" would probably include most if not all UN*X systems:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html
does not contain the string 2006 anywhere in it, so I view it as making an implicit promise that localtime() can convert any value of "seconds since the Epoch" to local time
Those go back to 1907, and that's on 32-bit systems.
The thing is, most users won't actually _have_ files whose timestamps they care about to-the-hour accuracy in displaying their timestamps in local time. And those who do can pick advanced.
Define "users". Do you mean "administrators" for big machines and "end users" for personal machines? Presumably if users can "pick advanced", the *system vendors* have to ship the full set of time zone files (otherwise, "advanced" isn't available). As long as they're doing that, presumably "pick advanced" is an option used in whatever UI is offered to choose the system's time zone, which will, for example, mean that, for the US, options such as "that part of Indiana that didn't do DST" will show up only if they "pick advanced". Of course, it's ultimately up to the system vendors to decide whether to offer "pick advanced" as an option or just to make it the default (or not to offer "advanced" at all, but I really doubt they'd do that). If they don't deem this choice useful, I suspect it's not worth our while to offer it.
We already don't handle (to make up an arbitrary example) people who moved from New York to Phoenix in 1992, but spent a month-long vacation in Florida in 2004.
We don't handle that because UN*X APIs don't offer a mechanism for saying "please use the time zone I was in at a given time to convert that time"; if they did, they could use our database for that.
On Wednesday, May 22, 2013 12:24:39 Guy Harris wrote:
We already don't handle (to make up an arbitrary example) people who moved from New York to Phoenix in 1992, but spent a month-long vacation in Florida in 2004.
We don't handle that because UN*X APIs don't offer a mechanism for saying "please use the time zone I was in at a given time to convert that time"; if they did, they could use our database for that.
D's standard library can do that sort of thing, but it's forced to read the files directly (and Boost has something similar, though IIRC, they maintain the TZ information in a different format rather than using the system's TZ files). The *nix C API is definitely limited with regards to time and time zones. However, at least *nix _has_ the right information thanks to the tzdata files. The built-in Windows stuff is way worse off in that regard. In any case, to answer the general topic, I would argue that the "advanced" stuff is the set of time zones that people don't normally use. There are over 1000 time zones in tzdata. Most people don't use more than one and don't care that most of them exist. They just pick America/New_York or Europe/Paris or whatever and it works just fine. I don't see any benefit in merging any of that. As it is, Linux installers typically either automatically determine your time zone or ask you to select your location on a map. In either case, you usually only have to worry about picking an actual time zone file when using a distro like Gentoo or Arch where you're managing most everything yourself directly rather than using GUI tools. So, I see no merit whatsoever in this proposal. And some people _do_ care about historical dates, and the fact that the tzdata files do as good a job with that as they do is fantastic (in contrast, Windows is lucky if it gets the date and time of a DST switch right if it's not in the US). - Jonathan M Davis
On Wed, May 22, 2013, at 16:00, Jonathan M Davis wrote:
In any case, to answer the general topic, I would argue that the "advanced" stuff is the set of time zones that people don't normally use. There are over 1000 time zones in tzdata. Most people don't use more than one and don't care that most of them exist. They just pick America/New_York or Europe/Paris or whatever and it works just fine. I don't see any benefit in merging any of that.
By "merging" I don't mean _actually_ merging anything in the database, I mean _expecting_ people to pick New_York (or, for example, a single CET zone, whichever one it may be, whether they're in France or Germany or Norway...), and putting the extra dozens of timezones that are the same today behind an 'advanced' screen. I simply titled this thread that because merging was what Paul Eggert's less ambitious proposal was stated in terms of.
"Jonathan M Davis" <jmdavisProg@gmx.com> writes:
On Wednesday, May 22, 2013 12:24:39 Guy Harris wrote:
We already don't handle (to make up an arbitrary example) people who moved from New York to Phoenix in 1992, but spent a month-long vacation in Florida in 2004.
We don't handle that because UN*X APIs don't offer a mechanism for saying "please use the time zone I was in at a given time to convert that time"; if they did, they could use our database for that.
D's standard library can do that sort of thing, but it's forced to read the files directly (and Boost has something similar, though IIRC, they maintain the TZ information in a different format rather than using the system's TZ files). The *nix C API is definitely limited
Boost uses CSV with current offset and rules that look similar to what's in POSIX TZ string. It doesn't nearly capture the whole of zoneinfo. If that's what you mean. And, BTW, how does D do it? Does it record the current TZ with the mtime or some such? It seems this would need some sort of log recording where the user was when. Thanks, PM
This paragraph from Random832 was just quoted: | We already don't handle (to make up an arbitrary example) people | who moved from New York to Phoenix in 1992, but spent a month-long | vacation in Florida in 2004. And I realize I don't understand what this is getting at. (Maybe this is unimportant?) We don't have zones that track people movements, and I don't see why we would. If someone moves from NY to FL to AZ they change their computers' timezones at each transition. What's the problem? *confused* --jhawk@mit.edu John Hawkinson
On Thu, May 23, 2013, at 8:35, John Hawkinson wrote:
This paragraph from Random832 was just quoted: | We already don't handle (to make up an arbitrary example) people | who moved from New York to Phoenix in 1992, but spent a month-long | vacation in Florida in 2004.
And I realize I don't understand what this is getting at. (Maybe this is unimportant?)
We don't have zones that track people movements, and I don't see why we would.
Why do we have zones that track _cities'_ movements from one timezone to another? It's arbitrary to demand one (to the point of objecting to putting it behind an 'advanced' option) but not the other.
random832@fastmail.us said:
Why do we have zones that track _cities'_ movements from one timezone to another?
We don't. We *define* a timezone as being a geographical area where all the clocks should always show the same time since 1970. Therefore a city *never* moves from one timezone to another. If a geographical area should have clocks showing different times in (say) April 1996, then that area contains more than one time zone. We do *NOT* use "timezone" to refer to *concepts* like "Eastern Standard Time" or "British Summer Time"; let alone "North American Eastern Time". (I think we have GMT+/-N zones, but that's because they are used at sea and so have geographic meaning.) We could add such zones, but these would be *additional* timezones. A city would not move from the NACT zone to the NAET zone; rather, it remains in its own zone, which shows the same time as NACT before the transition date and the same time as NAET after it. -- 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
While there have been a flurry of proposals on this list, the current process and format has worked just fine for many years. For every person pleased by any of these proposals, I strongly suspect there will be at least one other displeased—and probably many. (The people who are likely to complain are also more likely to be members of this list, while those who are content with the current system are less likely.) So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Thu, May 23, 2013 at 3:31 PM, Clive D.W. Feather <clive@davros.org>wrote:
random832@fastmail.us said:
Why do we have zones that track _cities'_ movements from one timezone to another?
We don't.
We *define* a timezone as being a geographical area where all the clocks should always show the same time since 1970. Therefore a city *never* moves from one timezone to another. If a geographical area should have clocks showing different times in (say) April 1996, then that area contains more than one time zone.
We do *NOT* use "timezone" to refer to *concepts* like "Eastern Standard Time" or "British Summer Time"; let alone "North American Eastern Time". (I think we have GMT+/-N zones, but that's because they are used at sea and so have geographic meaning.)
We could add such zones, but these would be *additional* timezones. A city would not move from the NACT zone to the NAET zone; rather, it remains in its own zone, which shows the same time as NACT before the transition date and the same time as NAET after it.
-- 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
On 23 May 2013 15:25, Mark Davis ☕ <mark@macchiato.com> wrote:
While there have been a flurry of proposals on this list, the current process and format has worked just fine for many years. For every person pleased by any of these proposals, I strongly suspect there will be at least one other displeased—and probably many. (The people who are likely to complain are also more likely to be members of this list, while those who are content with the current system are less likely.)
So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is.
+1 Stephen
+1 If there is indeed an "easier to maintain gain" by simply linking certain time zones to one that has the same definition , no problems there. Aldo I doubt to see much added value in doing so, most likely it are rather stable definitions anyway. While the "official" boundary is 1970 I would personally not want to get rid of any historical info (pre 1970) that is already there if this is done. Gunther On 23/05/2013 16:25, Mark Davis ☕ wrote:
While there have been a flurry of proposals on this list, the current process and format has worked just fine for many years. For every person pleased by any of these proposals, I strongly suspect there will be at least one other displeased—and probably many. (The people who are likely to complain are also more likely to be members of this list, while those who are content with the current system are less likely.)
So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is.
Mark <https://plus.google.com/114199149796022210033> / / /— Il meglio è l’inimico del bene —/ //
On Thu, May 23, 2013 at 3:31 PM, Clive D.W. Feather <clive@davros.org <mailto:clive@davros.org>> wrote:
random832@fastmail.us <mailto:random832@fastmail.us> said: > Why do we have zones that track _cities'_ movements from one timezone to > another?
We don't.
We *define* a timezone as being a geographical area where all the clocks should always show the same time since 1970. Therefore a city *never* moves from one timezone to another. If a geographical area should have clocks showing different times in (say) April 1996, then that area contains more than one time zone.
We do *NOT* use "timezone" to refer to *concepts* like "Eastern Standard Time" or "British Summer Time"; let alone "North American Eastern Time". (I think we have GMT+/-N zones, but that's because they are used at sea and so have geographic meaning.)
We could add such zones, but these would be *additional* timezones. A city would not move from the NACT zone to the NAET zone; rather, it remains in its own zone, which shows the same time as NACT before the transition date and the same time as NAET after it.
-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org <mailto:clive@davros.org> | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 <tel:%2B44%207973%20377646>
On Thu, 23 May 2013, Mark Davis ☕ wrote:
While there have been a flurry of proposals on this list, the current process and format has worked just fine for many years. For every person pleased by any of these proposals, I strongly suspect there will be at least one other displeased—and probably many. (The people who are likely to complain are also more likely to be members of this list, while those who are content with the current system are less likely.)
So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is.
I very much agree with that. Stability is very important. cheers, Derick
From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Mark Davis ? Sent: 23 May 2013 15:26
While there have been a flurry of proposals on this list, the current process and format has worked just fine for many years. For every person pleased by any of these proposals, I strongly suspect there will be at least one other displeased— and probably many. (The people who are likely to complain are also more likely to be members of this list, while those who are content with the current system are less likely.)
So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is.
+1 I also appreciate the presence of historical data prior to 1970. Regards, Stephen Goudge Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU www.petards.com 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 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
On 5/24/2013 2:08 AM, Goudge, Stephen wrote:
So on the principle that "if it ain't broke, don't fix it", we'd be better off just leaving the system as is. +1
I also appreciate the presence of historical data prior to 1970.
+1 +1 Eric.
On Wed, May 22, 2013, at 15:24, Guy Harris wrote:
Define "users". Do you mean "administrators" for big machines and "end users" for personal machines?
Whoever picks time zones, including end users on big machines that allow end users to configure how times are displayed to them (speaking of all UN*X systems...)
Presumably if users can "pick advanced", the *system vendors* have to ship the full set of time zone files (otherwise, "advanced" isn't available).
I am not proposing reducing the timezone files that are shipped, merely adding a way to have fewer timezones to choose from in the UI. No-one _now_, to my knowledge, doesn't ship the backwards-compatibility links, and they're even less useful than the ones I'm proposing de-emphasizing.
We don't handle that because UN*X APIs don't offer a mechanism for saying "please use the time zone I was in at a given time to convert that time"; if they did, they could use our database for that.
Why is that not what localtime() means? And if it _doesn't_ mean that, why doesn't localtime simply _always_ use Eastern for people in Vincennes, despite the fact that "the time zone they were in at a given time" was Central for part of 2006-2007?
On May 22, 2013, at 1:14 PM, random832@fastmail.us wrote:
On Wed, May 22, 2013, at 15:24, Guy Harris wrote:
Presumably if users can "pick advanced", the *system vendors* have to ship the full set of time zone files (otherwise, "advanced" isn't available).
I am not proposing reducing the timezone files that are shipped, merely adding a way to have fewer timezones to choose from in the UI.
The only UI we ship is tzselect; nothing we do prevents vendors from providing a UI that works the way you suggest on top of our current database.
We don't handle that because UN*X APIs don't offer a mechanism for saying "please use the time zone I was in at a given time to convert that time"; if they did, they could use our database for that.
Why is that not what localtime() means?
Because nobody's ever bothered to implement that behavior.
And if it _doesn't_ mean that, why doesn't localtime simply _always_ use Eastern for people in Vincennes, despite the fact that "the time zone they were in at a given time" was Central for part of 2006-2007?
Why should it? "localtime() doesn't know where you happened to be at some time in the past" does not imply "localtime() shouldn't care whether where you are *now* happens to have changed its {time zone offset, DST rules, time zone name} at some time in the past".
Date: Wed, 22 May 2013 16:14:40 -0400 From: random832@fastmail.us Message-ID: <1369253680.19347.140661234432069.5815BFD1@webmail.messagingengine.com> | Why is that not what localtime() means? It means the the time according to wherever you have defined the system's current locality to be. The interface has no direct way to know what other zones might have been a better fit for some particular file, or timestamp, all it is given is a single timestamp with no additional data (except what has been set as the timezone). This isn't our API, it way predates the tz project, all we do is make the interface that had been defined work properly, everywhere, rather than just in the US (using 1970's vintage summer time rules) which is what came before (or the various attempts using specifications encoded in evnrionment variables that have gradually gotten closer to rational, but also are now so complex as to be almost incomprensible - and still get it wrong). If more than current locality local time is needed, the application needs to alter the timezone before calling localtime. If it does that, the timezone data works fine. You seem to be advocating a system where all timestamps are created (and retained) in local time, rather than UTC - so that if I create a file at 15:00, move to a different timezone, and look at the file it will still say 15:00, regardless of their being another file that I more recently created claiming (correctly) to be 14:00 on the same day (becase I moved west very quickly, or more likely, east across the date line). There are systems that do that, and they're truly disgusting... The slight weirdness of having a file which I created at 15:00 later show up as having been made at 10:00 in my new local frame of reference is easy to come to grips with. I did make it at 10:00 (where I now am). In an easelier message, random832@fastmail.us quoted Guy Harris: | > so I view it as making an implicit promise that localtime() can convert | > any value of "seconds since the Epoch" to local time and then said: | Those go back to 1907, and that's on 32-bit systems. No, the Epoch is 1970 (1970-01-01 00:00:00 UTC). Times before that, when they can be represented (when time_t is signed, which is common, but I think not guaranteed) are before the Epoch, not since it. But (again personally) I'd like to gradually push the tzdata reference point backwards, there are systems that can represent times before the epoch, and it would be good to be able to correctly convert those as well- at least back to about the beginnings of standardised time (or the earliest that can be represented on the system if that is later than the beginning of standardiesd time). It isn't urgent that we do that (to put it very mildly) and we do include data before the epoch when somenle locates a source to tell us what it should be - eventually when that should lead to more zone splits, I'd like to see those happen. Attempting to make things easier for users by introucing subtle bugs in their systems isn't really a sensible desire - especially as what we're talking about is something that most people do once - and if they ever do need to repeat it, subsequesnt configs are typically very easy as the user knows what is going on and how the interface works - it is only the first time where this stuff ever looks complicated. random832@fastmail.us said: | We already don't handle (to make up an arbitrary example) people who moved | from New York to Phoenix in 1992, but spent a month-long vacation in Florida | in 2004. We don't provide the data, as we have no idea what that data should be, and there wouldn't be enough consumers for it in any case to make it worthwhile distributing. But tzdata certainly can handle it, if you want to, you can easily make a new private zone file with whatever jumps of local clock time that represent your own idea of reality. Once that's done, everything will use it just fine, just the same as any other zone. If you don't like the syntax of the zone files, you could easily write an application with a nice GUI interface that would allow users to create a zone (in zic input format - output of the application - or even in binary zone file format directly) that would make it as easy for the users as you want it to be. By all means, go ahead, but don't expect it to become a part of this project (a link to it from the web page would probably happen, but that's it.) random832@fastmail.us said: | Since you can't define zones in terms of other zones, we don't even make it | easy for them to handle themselves. You could also write an application (probably even just a script) that would do it that way as well - extracting parts of other zones and combining them together to make a new zone specification. Again, feel free. kre
On Thursday, May 23 2013, "Robert Elz" wrote to "random832@fastmail.us, tz@iana.org list" saying:
But (again personally) I'd like to gradually push the tzdata reference point backwards, there are systems that can represent times before the epoch, and it would be good to be able to correctly convert those as well- at least back to about the beginnings of standardised time (or the earliest that can be represented on the system if that is later than the beginning of standardiesd time).
Pushing the reference point earlier than the passage of the U.S. Uniform Time Act (April 13, 1966) would be a terrible idea. Prior to that, in the U.S., Daylight Savings rules were under local control, and were thus insanely complicated as different municipalities could (and did) make up their own rules. Trying to record all this knowledge would be a huge amount of work, and increase the number of U.S. zones enormously, for (IMO) almost no practical gain. Given that, I don't think there's much benefit to pushing the reference point back less than four years. -- Jonathan Lennox lennox@cs.columbia.edu
On 22 May 2013 20:16, Robert Elz <kre@munnari.oz.au> wrote:
random832@fastmail.us said: | Since you can't define zones in terms of other zones, we don't even make it | easy for them to handle themselves.
You could also write an application (probably even just a script) that would do it that way as well - extracting parts of other zones and combining them together to make a new zone specification. Again, feel free.
Why *don't* we support defining zones in terms of other zones? I presume someone has brought up the suggestion in the past. I can certainly see both sides of that argument. We have several comments with "like America/New_York" etc. throughout the data which could simply be replaced with actual syntax to the same effect. This would cause zones to be linked, but only within the limited scope of certain temporal boundaries (with "max" being a valid boundary, of course). The obvious upside would be that there's only one place to change rules if they're modified later as a group. The obvious downside is that when rules change for only part of a group, it's more work to track all of the data down. We'd also want to be careful to limit chaining and especially avoid recursion. Has there been a discussion on this before, and if so, can anyone who was around at the time recall its conclusions? -- Tim Parenti
The CLDR project already does with its concept of "meta zones" which group together similar tz identifiers under a single, human-friendly name. On Wed, May 22, 2013 at 11:27 AM, <random832@fastmail.us> wrote:
Or, more precisely, on the subject evicting redundant timezones from the user selection menu, since of course all current names will continue to exist as links if nothing else.
I've thought about this some more, and I don't think it goes far enough. A user installing a new system doesn't _care_ about (my own proper time zone) America/Indianapolis, they don't have any need to accurately convert times from before _2006_ let alone 1970. Most users could probably be served just as well with America/New_York.
I think it would be useful - particularly if we're abandoning being able to narrow it down by country - to define a heavily cut down set of "basic" time zones, that define each set of rules that exists _now_ without care for maintaining the past back to 1970, and then offer an "advanced" option for the rest.
-- Random832
-- Scott Atwood
On Wed, May 22, 2013, at 15:12, Scott Atwood wrote:
The CLDR project already does with its concept of "meta zones" which group together similar tz identifiers under a single, human-friendly name.
No, they group together identifiers that share the same _time zone name_ (e.g. "Eastern Time" or "Central European Time"). Notably, they do not separate zones that have different [present] daylight savings rules, because the CLDR's goal with it is [as far as I can tell] solely a matter of localizable presentation of time zone names, and you can use isdst to determine whether to display the standard or daylight name. The metazone relationship is absolutely unsuitable for user selection of a time zone rule.
I think all the proposals are a mistake (dropping zone.tab, merging timezones, etc.). We may like to pretend the tz database doesn't contain political information, but it simply is not so. We may like to think users don't use TZ idenfiers, but it simply isn't so. Forcing users who are happy with their current identifiers to use other ones (or making the ones they are currently using non-canonical) will simply annoying people and create a lot of stress. I think we are best served with the status quo. ( But of course, I also think that in the US, users should use US/Eastern instead of America/New_York, and that should be presented by tzselect and friends. ) --jhawk@mit.edu John Hawkinson
On May 22, 2013, at 5:35 PM, John Hawkinson <jhawk@mit.edu> wrote:
( But of course, I also think that in the US, users should use US/Eastern instead of America/New_York, and that should be presented by tzselect and friends. )
I, on the other hand, think users should, in the best of circumstances, not be presented with anything at all, and have the system automatically pick the right zone and, in circumstances where that's not possible, the user should be presented with a map that lets them pick a location, and users should never have to see a TZ identifier.
Guy Harris <guy@alum.mit.edu> wrote on Wed, 22 May 2013 at 17:43:42 -0700 in <3DBE1853-4746-467A-8BC5-6040546C1226@alum.mit.edu>:
I, on the other hand, think users should, in the best of circumstances, not be presented with anything at all, and have the system automatically pick the right zone and, in circumstances where that's not possible, the user should be presented with a map that lets them pick a location, and users should never have to see a TZ identifier.
"That's nice," but we're not there yet. And some consumers of the database will never have graphical interfaces. And I don't forsee a good solution to ancillary uses of tz identifiers for doing computation and determining "what time is it over there"? I still regularly type TZ=Asia/Calcutta date to determine the time in Bangalore, India, before sending email to folks there. And I even have graphical tools that show me some such times, but they're not always sufficient. --jhawk@mit.edu John Hawkinson
On May 22, 2013, at 5:47 PM, John Hawkinson <jhawk@mit.edu> wrote:
Guy Harris <guy@alum.mit.edu> wrote on Wed, 22 May 2013 at 17:43:42 -0700 in <3DBE1853-4746-467A-8BC5-6040546C1226@alum.mit.edu>:
I, on the other hand, think users should, in the best of circumstances, not be presented with anything at all, and have the system automatically pick the right zone and, in circumstances where that's not possible, the user should be presented with a map that lets them pick a location, and users should never have to see a TZ identifier.
"That's nice," but we're not there yet.
Well, maybe you're not, but I am. :-) Hopefully people designing time zone selectors for at least *some* desktop environments have looked at at least *one* OS X machine....
I still regularly type
TZ=Asia/Calcutta date
to determine the time in Bangalore, India, before sending email to folks there.
So do I, but I don't consider it the tz database folks' responsibility not to confuse or upset me by choosing the "wrong" city or.... I view zone names the way I view LANG settings - cryptic strings designed by nerds for nerds and software, not stuff the average user should expect to be straightforward.
On May 23, 2013, at 7:52 AM, Eliot Lear <lear@cisco.com> wrote:
On 5/23/13 2:47 AM, John Hawkinson wrote:
"That's nice," but we're not there yet.
Complain to your vendor. RFC-4833 was meant to take a big bite out of this, but Apple has chosen to go with a geo-service,
Apple has to be prepared to go with geolocation anyway; if the DHCP servers don't offer time zone information, the clients either have to ask the user or figure out out themselves, and geolocation will handle the latter if you have zone boundaries. Yes, OS X probably *should* ask for one or both of them in its DHCP client, and use it/them *if* they're offered, but if they don't get time zone information from the DHCP server, they need to fall back on geolocation. Their own base stations run NetBSD (in the current versions; older ones ran some simpler embedded OS) so they could offer the base station TZ setting from its DHCP server (I don't know how the base station gets its TZ setting - the old 5.x AirPort Utility let you set it, as I remember, but the Shiny New 6.x AirPort Utility doesn't; my guess is it's doing geolocation with Skyhook or something such as that).
and Microsoft has not yet acted, so far as I know.
I think they could turn POSIX TZ strings into rules for Windows, but they might have to pick up the Olson database in order to handle tz database TZ strings.
On May 23, 2013, at 11:13 PM, Random832 <random832@fastmail.us> wrote:
On 05/23/2013 06:51 PM, Guy Harris wrote:
I think they could turn POSIX TZ strings into rules for Windows, but they might have to pick up the Olson database in order to handle tz database TZ strings. CLDR contains a mapping.
...that maps some, but not all, Olson database zone names to Windows zones: http://cldr.unicode.org/development/development-process/design-proposals/ext... "Unmappable Olson Time Zones There are two kinds of unmappable Olson time zones. The first category is a set of Olson time zones that do not have the same base offset in Windows repertoires. The following zones belong to this category for now. Olson time zone Base UTC offset Australia/Eucla +08:45 Australia/Lord_Howe +10:30 Etc/GMT-14 +14:00 Pacific/Chatham +12:45 Pacific/Kiritimati +14:00 Pacific/Marquesas -09:30 Pacific/Norfolk +11:30 Because the mapping such zone to a Windows zone is harmful, these Olson time zones are excluded in the mapping data. The second category is a set of Olson time zone that do not have any Windows time zones with equivalent (or similar) daylight saving time rule. The following zones belong to this category. Olson time zone Comment America/Adak -10:00/DST(US rule). (UTC-10:00) Hawaii is only the Windows zone using -10 hour offset, but no DST is observed. Etc/GMT+8 -08:00/No DST. Windows has two zones with -8 hour offset - (UTC-08:00) Pacific Time (US & Canada) and (UTC-08:00) Baja California - but both of them observe DST. America/Metlakatla Pacific/Pitcairn Etc/GMT+9 -09:00/No DST. (UTC-09:00) Alaska is only the Windows zone using -9 hour offset, but it observes DST. Pacific/Gambier Pacific/Easter -06:00/DST(Southern Hemisphere style rule). Windows has two zones with -6 hour offset and DST enabled - (UTC-06:00) Central Time (US & Canada) and (UTC-06:00) Guadalajara, Mexico City - but both of them uses Northern Hemisphere style DST rules. America/Miquelon -03:00/DST(Canada rule). (UTC-03:00) Greenland is the closest match (-3 hour offset, EU style DST rule). However, Canada rule used by Miquelon differs from EU rule used by Greenland by 2 or 3 weeks on DST start, 1 week on DST end. Olson time zone with no DST above (such as Etc/GMT+8) could be mapped to a Windows time zone using the same base offset, because Windows allow users to turn off daylight saving time in the control panel or via Windows API. However, it still requires extra operation, so we do not include these mappings. Significant difference in daylight saving time rules will result mapped zone to return incorrect time zone offset (for both direction), we also exclude these DST incompatible zones from the mapping data." They could, I guess, just say "if you have a Windows box, using a DHCP server that coughs up time zone information, on Easter Island, you're out of luck"... which I guess you are, regardless of whether you're using your DHCP server for time zone rules or not, if there are no Windows zone settings that support a -6 hour offset and Southern Hemisphere-style DST rules.
On May 22, 2013, at 8:35 PM, John Hawkinson wrote:
I think all the proposals are a mistake (dropping zone.tab, merging timezones, etc.).
We may like to pretend the tz database doesn't contain political information, but it simply is not so.
We may like to think users don't use TZ idenfiers, but it simply isn't so.
Forcing users who are happy with their current identifiers to use other ones (or making the ones they are currently using non-canonical) will simply annoying people and create a lot of stress.
I think we are best served with the status quo.
I think so too. But various people have been grinding various political axes (to be charitable; I will continue to refrain from calling it what I actually believe it is because I don't want to start a major flame war) long enough that the people doing real work seem to be looking for some tolerable compromise. paul
On 22 May 2013 20:49, <Paul_Koning@dell.com> wrote:
I think we are best served with the status quo.
I think so too. But various people have been grinding various political axes
I agree. But I feel that people have taken the opportunity to grind those axes, in part, because of confusion over what the status quo actually is. As far as I'm aware, we currently match ISO 3166-1 with very few (albeit contentious) exceptions. Is that correct? Since we can't possibly get the entire world to agree on a single standard for this political aspect of the data, perhaps we'd be better served by instead using some (minimal) threshold of agreement amongst multiple standards? Or perhaps not. Frankly, I can see such an arrangement potentially creating more issues than it solves. Either way, I feel we should consider solidifying what our standard(s) are going forward, perhaps even putting it in an official document like an RFC, and then making sure our data matches. Currently, Theory only says we use ISO 3166-1 to "help decide", which opens the door to lots of the arguments we've seen in recent months. Regardless of what we pick, some people will inevitably not like it (that won't be anything new), but at least we'd be able to point to something that says "this is how we've chosen to do things." -- Tim Parenti
I second (or third, or whatever the number may be) this On May 22, 2013, at 20:35, John Hawkinson <jhawk@mit.edu> wrote:
We may like to pretend the tz database doesn't contain political information, but it simply is not so.
We may like to think users don't use TZ idenfiers, but it simply isn't so.
Forcing users who are happy with their current identifiers to use other ones (or making the ones they are currently using non-canonical) will simply annoying people and create a lot of stress.
I think we are best served with the status quo.
participants (20)
-
Clive D.W. Feather -
Derick Rethans -
Eliot Lear -
Eric Muller -
Goudge, Stephen -
gunther vermeir -
Guy Harris -
Isaac Hogue -
John Hawkinson -
Jonathan M Davis -
lennox＠cs.columbia.edu -
Mark Davis ☕ -
Paul_Koning＠Dell.com -
Petr Machata -
Random832 -
random832＠fastmail.us
-
Robert Elz -
Scott Atwood -
Stephen Colebourne -
Tim Parenti