Reason for removal of several TZ
Hi guys, Almost a year ago, commit 2999bb5bee719acbba8b9dd50fb9fb00c7788623 removed several TZ abbreviations and I'm trying to understand this. For my own use, what I'm after is WGT/WGST which are now "simply -03". WGT/WGST has been in tzdata for a long time, so the removal causes certain things to go belly up. The change was only implemented in Ubuntu recently, which is why this only turned into a problem for me now. WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone. So can someone explain to me the reason behind the removal and what would needed to get it re-implemented? Thanks. /Thomas
On 3 December 2017 at 08:05, Thomas M Steenholdt <tmus@tmus.dk> wrote:
Hi guys,
Almost a year ago, commit 2999bb5bee719acbba8b9dd50fb9fb00c7788623 removed several TZ abbreviations and I'm trying to understand this.
As that commit <https://github.com/eggert/tz/commit/2999bb5bee719acbba8b9dd50fb9fb00c7788623...> says, it's a switch away from "invented abbreviations". `git blame` shows their provenance dates back to this commit <https://github.com/eggert/tz/commit/eaaf2800958609851cfa66899bd811196b950d61...> from 1996-09-08, which clearly states that the abbreviations were invented by Paul Eggert and did not reflect any common usage at the time. Since 2015-08-07, our policy has shifted <https://github.com/eggert/tz/commit/32282b1278cbad59d7c755df705425e2b486a848> to *recording* existing usage rather than inventing it, and efforts over the last ~2 years have been toward removing past inventions like this where there is no other justification for keeping them. (Search the NEWS file for "invented", or just observe the number of zones now with numeric "abbreviations".) WGT/WGST seems to be a widely accepted abbreviation for the West
Greenland Time zone. So can someone explain to me the reason behind the removal and what would needed to get it re-implemented?
Basically, proof supporting your point that it is "widely accepted". Specifically, that it is a reasonably-commonly used abbreviation in English-language news reports, official documents, etc. by media, government, and the like, and in particular, that such usage is *not* primarily influenced simply by the abbreviations having been used by tz in the past. It's not an insurmountable bar, but it does require a bit more documentation than a simple assertion. -- Tim Parenti
Thomas M Steenholdt wrote:
WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone.
As far as I can see, it's an invented abbreviation propagated from tzdata, and there isn't much independent support for it. I've been trying to omit these inventions, as tzdata should record timekeeping not invent it.
the removal causes certain things to go belly up
Which things went belly up? Details might be helpful. Tim mentioned that we've been trying to omit invented abbreviations. In response to your email I reviewed them, and see one that should change (namely, "BOST" for Bolivia Summer Time 1931-2, should be "BST" to be consistent with abbreviations used elsewhere; we can't change it to numeric due to POSIX limits). There is at least one other abbreviation ("SET" for Swedish Time 1879-99) that I'm suspicious of, but not enough to try to change it now. At any rate, now that I've pretty much finished the job we should document the alphabetic abbreviations used. To give that a go I installed the attached patch into the development version on GitHub.
Paul Eggert wrote:
Thomas M Steenholdt wrote:
WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone.
As far as I can see, it's an invented abbreviation propagated from tzdata, and there isn't much independent support for it. I've been trying to omit these inventions, as tzdata should record timekeeping not invent it.
I totally agree. I just never thought this was something invented or unofficial - I've always used these. I have gathered a few sources that mention WGT/WGST, but I honestly have no clue if these are based of off tzdata (which could very well be the case) or something else.: https://www.timeanddate.com/time/zones/wgt https://www.worldtimeserver.com/time-zones/wgt/ http://www.prokerala.com/travel/timezones/Western_Greenland_Time http://www.datetime360.com/timezone-wgt/ https://www.worlddata.info/timezones/wgt-west-greenland-time.php In any case I can't help feeling, that with all this "knowledge" out there, removing the WGT/WGST timezone abbreviations from tzdata seems wrong. These are the TZ abbreviations that we work with on a daily basis up here (I'm in Nuuk, Greenland) and suddenly they are unknown in our favorite timezone data. So I'm more inclined to try to somehow make these abbreviations official. I just need to know where to start.
the removal causes certain things to go belly up
Which things went belly up? Details might be helpful.
From what I've seen, PHP (on Ubuntu) had some hiccups and started mentioning Sao Paolo in my date/time outputs, because WGT/WGST was suddenly missing:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1734967 A few of my own scripts that convert time between timezones started misbehaving as they expect WGT and WGST to be valid abbreviations. This is easy to fix, but there could be (and probably is) other places where this could cause problems. /Thomas
On Dec 3, 2017, at 9:04 PM, Thomas M Steenholdt <tmus@tmus.dk> wrote:
Paul Eggert wrote:
Thomas M Steenholdt wrote:
WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone.
As far as I can see, it's an invented abbreviation propagated from tzdata, and there isn't much independent support for it. I've been trying to omit these inventions, as tzdata should record timekeeping not invent it.
I totally agree. I just never thought this was something invented or unofficial - I've always used these.
It seems to me the notion of "official" doesn't always work. Sometimes a particular term is established merely by enough usage. In fact, that's how the English language works. So perhaps the same thinking should be applied here: it doesn't really matter where TZ names come from. Even if they were originally just an acronym thought up by PE or ADO, they become "real" if enough people use them as such. Now if you're dealing with invented names that haven't gotten any significant currency, that's different, then deleting them makes sense. But if the pushback is "wait a minute, everyone around here has been using that designation for at least a decade" then that makes it real enough to be preserved. That assumes there isn't contrary input from an actual "official" source, of course. paul
On 3 December 2017 at 21:13, <Paul.Koning@dell.com> wrote:
It seems to me the notion of "official" doesn't always work. Sometimes a particular term is established merely by enough usage. In fact, that's how the English language works.
Indeed. The standard isn't "official", merely "widely accepted".
So perhaps the same thinking should be applied here: it doesn't really matter where TZ names come from. Even if they were originally just an acronym thought up by PE or ADO, they become "real" if enough people use them as such.
Now if you're dealing with invented names that haven't gotten any significant currency, that's different, then deleting them makes sense. But if the pushback is "wait a minute, everyone around here has been using that designation for at least a decade" then that makes it real enough to be preserved. That assumes there isn't contrary input from an actual "official" source, of course.
Oh, certainly. Obviously official government documents would meet that standard, but other things could, too, hence the requests for use by newspapers and media outlets, for example. It's a big part of why the Australian abbreviations were changed to reflect common usage <https://github.com/eggert/tz/commit/62df86e10cb45ed931850f7298fa063ffea07544> a few years back. If it's indeed true that "everyone…has been using that designation", then it's generally easy to point to prominent examples. Unfortunately, most online compendia of world time zones — like those Thomas linked — tend to source their data, knowingly or unknowingly, from tz or its derivations, so they don't really count for these purposes. -- Tim Parenti
I believe that most people consider that the tz designations are in fact the official 'American' equivalents for the official local designations - which they are not. There are no official 'American' designations, and the tz maintainers repeatedly state that their designations are not made by political bodies. At the same time they certainly are not the local designations preferred by the locals, otherwise they wouldn't use English for Beijing, and numbers for Greenland. In effect, they are designations currently seem to be decided at whim by the tz maintainers according to their belief of what the most locals would use if they spoke English, or by using numbers if they don't know. This is their right, as it is their database. But clearly, as a tz database is required internationally and is of great significance, there should be clear rules stating how designations in the db are chosen or changed, or failing that, a database of internationally approved designations should be developed perhaps through an arm of the UN, and used separately. David Patte On 2017-12-03 21:24, Tim Parenti wrote:
On 3 December 2017 at 21:13, <Paul.Koning@dell.com <mailto:Paul.Koning@dell.com>> wrote:
It seems to me the notion of "official" doesn't always work. Sometimes a particular term is established merely by enough usage. In fact, that's how the English language works.
Indeed. The standard isn't "official", merely "widely accepted".
So perhaps the same thinking should be applied here: it doesn't really matter where TZ names come from. Even if they were originally just an acronym thought up by PE or ADO, they become "real" if enough people use them as such.
Now if you're dealing with invented names that haven't gotten any significant currency, that's different, then deleting them makes sense. But if the pushback is "wait a minute, everyone around here has been using that designation for at least a decade" then that makes it real enough to be preserved. That assumes there isn't contrary input from an actual "official" source, of course.
Oh, certainly. Obviously official government documents would meet that standard, but other things could, too, hence the requests for use by newspapers and media outlets, for example. It's a big part of why the Australian abbreviations were changed to reflect common usage <https://github.com/eggert/tz/commit/62df86e10cb45ed931850f7298fa063ffea07544> a few years back. If it's indeed true that "everyone…has been using that designation", then it's generally easy to point to prominent examples.
Unfortunately, most online compendia of world time zones — like those Thomas linked — tend to source their data, knowingly or unknowingly, from tz or its derivations, so they don't really count for these purposes.
-- Tim Parenti
--
Clearly if the tz maintainers don't want to invent designations, and don't want to use the official political designations, that all the designations should be only for timekeeping purposes, and should be replaced by numbers. But instead I believe that the db should record the official political designations (perhaps translated to English), as designated by the political entities themselves. This also includes using the English equivalent of the country names the people within these political regions designate for themselves. We could start with Palestine, which is recognized as a nation by 80% of countries, and 90% of the world population. On 2017-12-03 23:40, David Patte ₯ wrote:
I believe that most people consider that the tz designations are in fact the official 'American' equivalents for the official local designations - which they are not. There are no official 'American' designations, and the tz maintainers repeatedly state that their designations are not made by political bodies.
At the same time they certainly are not the local designations preferred by the locals, otherwise they wouldn't use English for Beijing, and numbers for Greenland.
In effect, they are designations currently seem to be decided at whim by the tz maintainers according to their belief of what the most locals would use if they spoke English, or by using numbers if they don't know. This is their right, as it is their database.
But clearly, as a tz database is required internationally and is of great significance, there should be clear rules stating how designations in the db are chosen or changed, or failing that, a database of internationally approved designations should be developed perhaps through an arm of the UN, and used separately.
David Patte
On 2017-12-03 21:24, Tim Parenti wrote:
On 3 December 2017 at 21:13, <Paul.Koning@dell.com <mailto:Paul.Koning@dell.com>> wrote:
It seems to me the notion of "official" doesn't always work. Sometimes a particular term is established merely by enough usage. In fact, that's how the English language works.
Indeed. The standard isn't "official", merely "widely accepted".
So perhaps the same thinking should be applied here: it doesn't really matter where TZ names come from. Even if they were originally just an acronym thought up by PE or ADO, they become "real" if enough people use them as such.
Now if you're dealing with invented names that haven't gotten any significant currency, that's different, then deleting them makes sense. But if the pushback is "wait a minute, everyone around here has been using that designation for at least a decade" then that makes it real enough to be preserved. That assumes there isn't contrary input from an actual "official" source, of course.
Oh, certainly. Obviously official government documents would meet that standard, but other things could, too, hence the requests for use by newspapers and media outlets, for example. It's a big part of why the Australian abbreviations were changed to reflect common usage <https://github.com/eggert/tz/commit/62df86e10cb45ed931850f7298fa063ffea07544> a few years back. If it's indeed true that "everyone…has been using that designation", then it's generally easy to point to prominent examples.
Unfortunately, most online compendia of world time zones — like those Thomas linked — tend to source their data, knowingly or unknowingly, from tz or its derivations, so they don't really count for these purposes.
-- Tim Parenti
--
--
David Patte ₯ wrote:
they are designations currently seem to be decided at whim by the tz maintainers according to their belief of what the most locals would use if they spoke English
It's not just locals; it's English-speakers in general.
there should be clear rules
Guidelines are here: https://data.iana.org/time-zones/theory.html Also see the most recent development version here: https://github.com/eggert/tz/blob/master/theory.html
the db should record the official political designation Although we cannot avoid politics entirely, we should strive to avoid as much as possible in tzdb. For example, tzdb should not take any position on Israel vs Palestine, North Korea vs South Korea, or Canada vs the United States. It's not our job to address such disputes and it would be a waste of our limited resources if the disputes got in the way of our job.
On 2017-12-04 02:52, Paul Eggert wrote:
Although we cannot avoid politics entirely, we should strive to avoid as much as possible in tzdb. For example, tzdb should not take any position on Israel vs Palestine, North Korea vs South Korea, or Canada vs the United States. It's not our job to address such disputes and it would be a waste of our limited resources if the disputes got in the way of our job.
Its convenient to frame Palestine in this manner, but if you truly wish to remove your own politics from the db, the politics of the Palestinians themselves should be the deciding factor here.
On 2017-12-04 07:05, David Patte ₯ wrote:
On 2017-12-04 02:52, Paul Eggert wrote:
Although we cannot avoid politics entirely, we should strive to avoid as much as possible in tzdb. For example, tzdb should not take any position on Israel vs Palestine, North Korea vs South Korea, or Canada vs the United States. It's not our job to address such disputes and it would be a waste of our limited resources if the disputes got in the way of our job.
Its convenient to frame Palestine in this manner, but if you truly wish to remove your own politics from the db, the politics of the Palestinians themselves should be the deciding factor here.
I wouldn't mind if the country codes were eliminated from zone.tab to avoid politics - it does not serve much function - make that another UI issue to argue with each distro or vendor! Until then we should go as usual with the de facto majority situation on the ground to avoid political claims. Unfortunately politicians seem to be allowed to decide which time zones should be observed where and when - the source of many of our problems: "Put not your trust in princes" although princesses may be more apposite ;^> I would prefer bureaucratic inertia to changes over political whims. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This issue always surfaces at one point or another. I and others have argued for a long time that timezone ids should be opaque. It's really up to some localization feature to provide meaningful names for those timezones. The data for those localization already exists - providing region/city names for timezones has just led people to believe they mean more than they do. I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. On 12/4/17 13:09, Brian Inglis wrote:
On 2017-12-04 07:05, David Patte ₯ wrote:
On 2017-12-04 02:52, Paul Eggert wrote:
Although we cannot avoid politics entirely, we should strive to avoid as much as possible in tzdb. For example, tzdb should not take any position on Israel vs Palestine, North Korea vs South Korea, or Canada vs the United States. It's not our job to address such disputes and it would be a waste of our limited resources if the disputes got in the way of our job. Its convenient to frame Palestine in this manner, but if you truly wish to remove your own politics from the db, the politics of the Palestinians themselves should be the deciding factor here. I wouldn't mind if the country codes were eliminated from zone.tab to avoid politics - it does not serve much function - make that another UI issue to argue with each distro or vendor! Until then we should go as usual with the de facto majority situation on the ground to avoid political claims. Unfortunately politicians seem to be allowed to decide which time zones should be observed where and when - the source of many of our problems: "Put not your trust in princes" although princesses may be more apposite ;^> I would prefer bureaucratic inertia to changes over political whims.
On Dec 4, 2017, at 11:52 AM, Michael Douglass <mikeadouglass@gmail.com> wrote:
This issue always surfaces at one point or another. I and others have argued for a long time that timezone ids should be opaque.
It's really up to some localization feature to provide meaningful names for those timezones. The data for those localization already exists - providing region/city names for timezones has just led people to believe they mean more than they do.
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it.
There are tzdb regions and there are time zones; the two are different - a tzdb region can be in different time zones at different times. Strings such as Europe/Berlin correspond to tzdb regions. Making those strings opaque would force UIs for selecting the tzdb region to provide something better than a list of tzdb region IDs, or of tzdb region IDs with minimal tweaks such as replacing underscores with spaces, as all too many currently do, and thus also reduce the level of complaints about "why isn't my important city listed?" or "why is this random city used rather than the city that *should* but used?" tzdb region IDs do not need to be localized; they need to be hidden from the UI. Strings such as WGT and WGST correspond to time zones. Those strings were, back when the tzdb and its sample code were originally created, provided by UN*X APIs, so the sample code - originally developed as a replacement for UN*X time conversion APIs - provided those APIs, and the tzdb provided values for them. *Those* should be localized. and are localized in the CLDR (http://cldr.unicode.org), which also provides long names.
On 2017-12-04 12:52, Michael Douglass wrote:
On 12/4/17 13:09, Brian Inglis wrote:
On 2017-12-04 07:05, David Patte ₯ wrote:
On 2017-12-04 02:52, Paul Eggert wrote:
Although we cannot avoid politics entirely, we should strive to avoid as much as possible in tzdb. For example, tzdb should not take any position on Israel vs Palestine, North Korea vs South Korea, or Canada vs the United States. It's not our job to address such disputes and it would be a waste of our limited resources if the disputes got in the way of our job. Its convenient to frame Palestine in this manner, but if you truly wish to remove your own politics from the db, the politics of the Palestinians themselves should be the deciding factor here. I wouldn't mind if the country codes were eliminated from zone.tab to avoid politics - it does not serve much function - make that another UI issue to argue with each distro or vendor! Until then we should go as usual with the de facto majority situation on the ground to avoid political claims.> This issue always surfaces at one point or another. I and others have argued for a long time that timezone ids should be opaque.> It's really up to some localization feature to provide meaningful names for those timezones. The data for those localization already exists - providing region/city names for timezones has just led people to believe they mean more than they do. I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc.
Using municipality names has always had the problems that the names are only unique within, and often span, internal administrative divisions, and sometimes continents; and may be changed by politicians, or change countries; whereas lat/longs are infrequently corrected and probably accurate enough across geodetic datum shifts. The datum is not specified in Theory: it probably should be. Has anyone ever checked to see, or knows from geodetic principles, if different datums used since inception of standard times makes any significant difference in coordinates? I know the deltas can be ~.5km: too large to be ignored for surveying and navigation applications. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Dec 4, 2017, at 1:36 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc.
Presumably "its lat/long" means "the latitude/longitude of (some point within) the city being used to give a name to the tzdb region".
On 2017-12-04 14:59, Guy Harris wrote:
On Dec 4, 2017, at 1:36 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc. Presumably "its lat/long" means "the latitude/longitude of (some point within) the city being used to give a name to the tzdb region".
The lat/long, that is already available as a semantic property in zone.tab, as a consistent, externally verifiable, id (not name) for i14n and UI references. We could then eliminate country codes and TZ names from zone.tab, and expand the comments to (perhaps multi-line, leading blank space continuation) textual descriptions of applicable countries (and their internal subdivisions), etc. in a new file e.g. id.tab or coord.tab. All links would also be changed to ids. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Dec 4, 2017, at 8:16 PM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
On 2017-12-04 14:59, Guy Harris wrote:
Presumably "its lat/long" means "the latitude/longitude of (some point within) the city being used to give a name to the tzdb region".
The lat/long, that is already available as a semantic property in zone.tab,
Which is, presumably, the latitude/longitude of (some point within) the city being used to give a name to the tzdb region. (Just out of curiosity, how was that point chosen? The commentary says "principal location", but an arc second on the Earth's surface is about 20-30 meters, so there are a lot of degrees/minutes/seconds points inside the Big Apple, and even with arc minutes, which are about 1.2-1.8 km, Manhattan Island is more than one arc minute high. The Wikipedia cites the U.S. Gazetteer: https://www.census.gov/geo/maps-data/data/gazetteer.html as saying that New York is at 40°42′46″N 74°00′21″W; are we using sources such as that and its equivalents for other countries?)
Guy Harris wrote:
(Just out of curiosity, how was that point chosen?
Originally I took zone*.tab latitudes and longitudes from Shanks, who I presume got it from some circa-1960 gazetteer (he does not list his sources). These coordinates are all to one arc-minute accuracy. Some of the more-recently edited coordinates have come from Wikipedia or suchlike sources. I haven't viewed the latitudes and longitudes as being important enough to support via cited sources, since they're intended only as a rough guide for a UI.
Brian Inglis said:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc.
What's wrong with just labelling the present zones with randomly allocated letter-digit-letter codes? That gives us 6760 codes that don't look like city names or commonly-used abbreviations. We can then reserve letter-letter-digit for future expansion and digit-letter-letter for private use. As soon as people know it's lat/long, they'll try to map it to cities and the same arguments will start again. -- 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 12/4/17 17:13, Clive D.W. Feather wrote:
Brian Inglis said:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc. What's wrong with just labelling the present zones with randomly allocated letter-digit-letter codes? That gives us 6760 codes that don't look like city names or commonly-used abbreviations. We can then reserve letter-letter-digit for future expansion and digit-letter-letter for private use.
As soon as people know it's lat/long, they'll try to map it to cities and the same arguments will start again. Exactly - that's why I said opaque
Le 4 déc. 2017 à 18:18, Michael Douglass <mikeadouglass@gmail.com> a écrit : Exactly - that's why I said opaque
I just came up with a system I think is opaque enough while still maintaining a bit of useful information in the id: First up, it goes with the letter-digit-letter format. The first letter represents the (lower) GMT offset of the zone in military format. (This represents the one real flaw I see: a zone’s proper letter can change if it adopts something on the order of year-round daylight savings time.) The digit is usually 0. It changes in the following cases: 3 would indicate a +:15 zone if there were any, 5 is a +:30 zone, and 8 is a +:45 zone. 1 is used with M (normally +12) to indicate +13, and M2 similarly indicates +14. 1 is also used with other letters when the 0 range overflows. The second letter is meaningless UNLESS it is Z. Z indicates a non-geographic time zone (the Etc/ series of indicators). The list I just randomized, presented in order of newID: Africa/Ndjamena a0a Africa/Tunis a0b Europe/Gibraltar a0c Europe/Monaco a0d Europe/Oslo a0e Europe/Warsaw a0f Europe/Zurich a0g Europe/Madrid a0h Europe/Copenhagen a0i Europe/Brussels a0j Europe/Malta a0k Europe/Andorra a0l Africa/Algiers a0m Europe/Paris a0n Europe/Amsterdam a0o Europe/Luxembourg a0p Africa/Ceuta a0q Europe/Tirane a0r Europe/Vienna a0s Europe/Belgrade a0t Europe/Budapest a0u Europe/Prague a0v Europe/Rome a0w Africa/Lagos a0x Europe/Stockholm a0y Etc/GMT-1 a0z Asia/Beirut b0a Europe/Bucharest b0b Europe/Riga b0c Africa/Khartoum b0d Asia/Damascus b0e Africa/Windhoek b0f Europe/Tallinn b0g Asia/Hebron b0h Africa/Maputo b0i Europe/Athens b0j Europe/Kiev b0k Europe/Sofia b0l Africa/Johannesburg b0m Europe/Chisinau b0n Europe/Zaporozhye b0o Asia/Famagusta b0p Asia/Nicosia b0q Africa/Tripoli b0r Europe/Uzhgorod b0s Asia/Jerusalem b0t Africa/Cairo b0u Asia/Amman b0v Asia/Gaza b0w Europe/Helsinki b0x Europe/Kaliningrad b0y Etc/GMT-2 b0z Europe/Vilnius b1a Europe/Minsk c0a Europe/Kirov c0b Africa/Nairobi c0c Antarctica/Syowa c0d Asia/Baghdad c0e Asia/Riyadh c0f Asia/Qatar c0g Europe/Istanbul c0h Africa/Juba c0i Europe/Moscow c0j Europe/Volgograd c0k Etc/GMT-3 c0z Asia/Tehran c5a Asia/Tbilisi d0a Europe/Saratov d0b Asia/Dubai d0c Europe/Samara d0d Indian/Reunion d0e Europe/Astrakhan d0f Indian/Mahe d0g Asia/Baku d0h Europe/Ulyanovsk d0i Asia/Yerevan d0j Indian/Mauritius d0k Etc/GMT-4 d0z Asia/Kabul d5a Asia/Samarkand e0a Asia/Aqtobe e0b Asia/Oral e0c Asia/Dushanbe e0d Asia/Karachi e0e Asia/Aqtau e0f Indian/Kerguelen e0g Asia/Yekaterinburg e0h Asia/Ashgabat e0i Asia/Tashkent e0j Antarctica/Mawson e0k Asia/Atyrau e0l Indian/Maldives e0m Etc/GMT-5 e0z Asia/Colombo e5a Asia/Kathmandu e8a Asia/Omsk f0a Asia/Dhaka f0b Antarctica/Vostok f0c Asia/Bishkek f0d Asia/Almaty f0e Asia/Thimphu f0f Asia/Urumqi f0g Asia/Qyzylorda f0h Indian/Chagos f0i Etc/GMT-6 f0z Asia/Yangon f5a Indian/Cocos f5b Asia/Pontianak g0a Asia/Tomsk g0b Asia/Bangkok g0c Asia/Hovd g0d Asia/Novokuznetsk g0e Asia/Jakarta g0f Asia/Krasnoyarsk g0g Antarctica/Davis g0h Asia/Barnaul g0i Asia/Novosibirsk g0j Indian/Christmas g0k Asia/Ho_Chi_Minh g0l Etc/GMT-7 g0z Asia/Singapore h0a Asia/Taipei h0b Asia/Makassar h0c Asia/Brunei h0d Asia/Kuching h0e Asia/Ulaanbaatar h0f Asia/Kuala_Lumpur h0g Asia/Choibalsan h0h Asia/Shanghai h0i Asia/Macau h0j Asia/Irkutsk h0k Asia/Hong_Kong h0l Asia/Manila h0m Australia/Perth h0n Etc/GMT-8 h0z Asia/Pyongyang h5a Australia/Eucla h8a Pacific/Palau i0a Asia/Khandyga i0b Asia/Seoul i0c Asia/Yakutsk i0d Asia/Dili i0e Asia/Chita i0f Asia/Jayapura i0g Asia/Tokyo i0h Etc/GMT-9 i0z Australia/Adelaide i5a Australia/Darwin i5b Australia/Broken_Hill i5c Australia/Brisbane k0a Pacific/Port_Moresby k0b Australia/Hobart k0c Australia/Sydney k0d Australia/Currie k0e Asia/Vladivostok k0f Australia/Lindeman k0g Australia/Melbourne k0h Asia/Ust-Nera k0i Antarctica/DumontDUrville k0j Pacific/Guam k0k Pacific/Chuuk k0l Etc/GMT-10 k0z Australia/Lord_Howe k5a Pacific/Bougainville l0a Pacific/Norfolk l0b Antarctica/Macquarie l0c Pacific/Kosrae l0d Asia/Sakhalin l0e Pacific/Noumea l0f Pacific/Guadalcanal l0g Asia/Magadan l0h Pacific/Efate l0i Asia/Srednekolymsk l0j Antarctica/Casey l0k Pacific/Pohnpei l0l Etc/GMT-11 l0z Pacific/Tarawa m0a Pacific/Nauru m0b Pacific/Majuro m0c Pacific/Fiji m0d Pacific/Kwajalein m0e Pacific/Wallis m0f Asia/Anadyr m0g Pacific/Wake m0h Pacific/Funafuti m0i Asia/Kamchatka m0j Pacific/Auckland m0k Etc/GMT-12 m0z Pacific/Tongatapu m1a Pacific/Fakaofo m1b Pacific/Enderbury m1c Pacific/Apia m1d Etc/GMT-13 m1z Pacific/Kiritimati m2a Etc/GMT-14 m2z Pacific/Chatham m8a Atlantic/Cape_Verde n0a Atlantic/Azores n0b America/Scoresbysund n0c Etc/GMT+1 n0z America/Noronha o0a Atlantic/South_Georgia o0b Etc/GMT+2 o0z America/Argentina/La_Rioja p0a America/Argentina/Catamarca p0b America/Montevideo p0c America/Argentina/Buenos_Aires p0d Antarctica/Rothera p0e America/Argentina/San_Juan p0f America/Sao_Paulo p0g America/Godthab p0h America/Araguaina p0i America/Argentina/Salta p0j America/Argentina/Mendoza p0k America/Santarem p0l America/Cayenne p0m America/Argentina/Tucuman p0n America/Argentina/Jujuy p0o Atlantic/Stanley p0p America/Argentina/Cordoba p0q America/Miquelon p0r America/Argentina/San_Luis p0s America/Belem p0t America/Maceio p0u America/Argentina/Ushuaia p0v America/Recife p0w America/Paramaribo p0x America/Bahia p0y Etc/GMT+3 p0z America/Fortaleza p1a America/Argentina/Rio_Gallegos p1b America/St_Johns p5a America/Blanc-Sablon q0a America/Grand_Turk q0b America/Goose_Bay q0c America/Glace_Bay q0d America/Guyana q0e America/Porto_Velho q0f America/Boa_Vista q0g America/Thule q0h America/Caracas q0i Atlantic/Bermuda q0j America/Martinique q0k America/Port_of_Spain q0l America/Campo_Grande q0m America/Halifax q0n America/Barbados q0o America/Moncton q0p America/Manaus q0q America/Santiago q0r America/La_Paz q0s America/Curacao q0t America/Santo_Domingo q0u America/Puerto_Rico q0v America/Asuncion q0w America/Cuiaba q0x Etc/GMT+4 q0z America/Cancun r0a America/Jamaica r0b America/Kentucky/Louisville r0c America/Rio_Branco r0d America/Indiana/Marengo r0e America/Kentucky/Monticello r0f America/Lima r0g America/Indiana/Winamac r0h America/Indiana/Indianapolis r0i America/New_York r0j America/Indiana/Vevay r0k America/Nipigon r0l America/Detroit r0m America/Guayaquil r0n America/Thunder_Bay r0o America/Panama r0p America/Iqaluit r0q America/Indiana/Vincennes r0r America/Bogota r0s America/Eirunepe r0t America/Atikokan r0u America/Indiana/Petersburg r0v America/Port-au-Prince r0w America/Nassau r0x America/Toronto r0y Etc/GMT+5 r0z America/Havana r1a America/Pangnirtung r1b America/Chicago s0a America/Resolute s0b America/Bahia_Banderas s0c America/North_Dakota/Beulah s0d America/Swift_Current s0e America/North_Dakota/Center s0f America/Winnipeg s0g America/El_Salvador s0h America/Indiana/Tell_City s0i America/Mexico_City s0j America/Costa_Rica s0k America/Monterrey s0l America/Tegucigalpa s0m America/Managua s0n America/Merida s0o America/Menominee s0p America/Rankin_Inlet s0q America/Belize s0r Pacific/Galapagos s0s America/Regina s0t America/Indiana/Knox s0u America/North_Dakota/New_Salem s0v Pacific/Easter s0w America/Rainy_River s0x America/Guatemala s0y Etc/GMT+6 s0z America/Matamoros s1a America/Edmonton t0a America/Chihuahua t0b America/Inuvik t0c America/Cambridge_Bay t0d America/Mazatlan t0e America/Hermosillo t0f America/Fort_Nelson t0g America/Boise t0h America/Yellowknife t0i America/Creston t0j America/Denver t0k America/Dawson_Creek t0l America/Phoenix t0m America/Ojinaga t0n Etc/GMT+7 t0z America/Tijuana u0a America/Los_Angeles u0b Pacific/Pitcairn u0c America/Vancouver u0d America/Whitehorse u0e America/Dawson u0f Etc/GMT+8 u0z America/Metlakatla v0a America/Anchorage v0b America/Juneau v0c America/Sitka v0d Pacific/Gambier v0e America/Yakutat v0f America/Nome v0g Etc/GMT+9 v0z Pacific/Marquesas v5a Pacific/Rarotonga w0a Pacific/Tahiti w0b Pacific/Honolulu w0c America/Adak w0d Etc/GMT+10 w0z Pacific/Pago_Pago x0a Pacific/Niue x0b Etc/GMT+11 x0z Etc/GMT+12 y0z Europe/Dublin z0a Africa/Abidjan z0b Atlantic/Faroe z0c Africa/Bissau z0d Atlantic/Madeira z0e Africa/Accra z0f Africa/Casablanca z0g Atlantic/Reykjavik z0h America/Danmarkshavn z0i Atlantic/Canary z0j Europe/Lisbon z0k Africa/Monrovia z0l Africa/El_Aaiun z0m Europe/London z0n Etc/UTC z0z Etc/GMT z0z
With a mapping table it doesn't matter what the id is. In fact any scheme for producing an id that is reversible or ordered in any way will lead to people using that then complaining down the road if you do something that "breaks" their code. I'd suggest writing a small routine to create an 8 character random base64 id and get a new random id for each new zone. (I'd suggest a uuid but they're bulky). Then create a legacy-mappings.txt file to map all the current names and aliases on to the new id - then we're sort of done. I'd suggest a simple increasing sequence but you can guarantee that somebody would use it as an index even if told not to. Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish. On 12/4/17 19:05, J Andrew Lipscomb wrote:
Le 4 déc. 2017 à 18:18, Michael Douglass <mikeadouglass@gmail.com> a écrit : Exactly - that's why I said opaque I just came up with a system I think is opaque enough while still maintaining a bit of useful information in the id: First up, it goes with the letter-digit-letter format.
The first letter represents the (lower) GMT offset of the zone in military format. (This represents the one real flaw I see: a zone’s proper letter can change if it adopts something on the order of year-round daylight savings time.)
The digit is usually 0. It changes in the following cases: 3 would indicate a +:15 zone if there were any, 5 is a +:30 zone, and 8 is a +:45 zone. 1 is used with M (normally +12) to indicate +13, and M2 similarly indicates +14. 1 is also used with other letters when the 0 range overflows.
The second letter is meaningless UNLESS it is Z. Z indicates a non-geographic time zone (the Etc/ series of indicators).
The list I just randomized, presented in order of newID:
Africa/Ndjamena a0a Africa/Tunis a0b Europe/Gibraltar a0c Europe/Monaco a0d Europe/Oslo a0e Europe/Warsaw a0f Europe/Zurich a0g Europe/Madrid a0h Europe/Copenhagen a0i Europe/Brussels a0j Europe/Malta a0k Europe/Andorra a0l Africa/Algiers a0m Europe/Paris a0n Europe/Amsterdam a0o Europe/Luxembourg a0p Africa/Ceuta a0q Europe/Tirane a0r Europe/Vienna a0s Europe/Belgrade a0t Europe/Budapest a0u Europe/Prague a0v Europe/Rome a0w Africa/Lagos a0x Europe/Stockholm a0y Etc/GMT-1 a0z Asia/Beirut b0a Europe/Bucharest b0b Europe/Riga b0c Africa/Khartoum b0d Asia/Damascus b0e Africa/Windhoek b0f Europe/Tallinn b0g Asia/Hebron b0h Africa/Maputo b0i Europe/Athens b0j Europe/Kiev b0k Europe/Sofia b0l Africa/Johannesburg b0m Europe/Chisinau b0n Europe/Zaporozhye b0o Asia/Famagusta b0p Asia/Nicosia b0q Africa/Tripoli b0r Europe/Uzhgorod b0s Asia/Jerusalem b0t Africa/Cairo b0u Asia/Amman b0v Asia/Gaza b0w Europe/Helsinki b0x Europe/Kaliningrad b0y Etc/GMT-2 b0z Europe/Vilnius b1a Europe/Minsk c0a Europe/Kirov c0b Africa/Nairobi c0c Antarctica/Syowa c0d Asia/Baghdad c0e Asia/Riyadh c0f Asia/Qatar c0g Europe/Istanbul c0h Africa/Juba c0i Europe/Moscow c0j Europe/Volgograd c0k Etc/GMT-3 c0z Asia/Tehran c5a Asia/Tbilisi d0a Europe/Saratov d0b Asia/Dubai d0c Europe/Samara d0d Indian/Reunion d0e Europe/Astrakhan d0f Indian/Mahe d0g Asia/Baku d0h Europe/Ulyanovsk d0i Asia/Yerevan d0j Indian/Mauritius d0k Etc/GMT-4 d0z Asia/Kabul d5a Asia/Samarkand e0a Asia/Aqtobe e0b Asia/Oral e0c Asia/Dushanbe e0d Asia/Karachi e0e Asia/Aqtau e0f Indian/Kerguelen e0g Asia/Yekaterinburg e0h Asia/Ashgabat e0i Asia/Tashkent e0j Antarctica/Mawson e0k Asia/Atyrau e0l Indian/Maldives e0m Etc/GMT-5 e0z Asia/Colombo e5a Asia/Kathmandu e8a Asia/Omsk f0a Asia/Dhaka f0b Antarctica/Vostok f0c Asia/Bishkek f0d Asia/Almaty f0e Asia/Thimphu f0f Asia/Urumqi f0g Asia/Qyzylorda f0h Indian/Chagos f0i Etc/GMT-6 f0z Asia/Yangon f5a Indian/Cocos f5b Asia/Pontianak g0a Asia/Tomsk g0b Asia/Bangkok g0c Asia/Hovd g0d Asia/Novokuznetsk g0e Asia/Jakarta g0f Asia/Krasnoyarsk g0g Antarctica/Davis g0h Asia/Barnaul g0i Asia/Novosibirsk g0j Indian/Christmas g0k Asia/Ho_Chi_Minh g0l Etc/GMT-7 g0z Asia/Singapore h0a Asia/Taipei h0b Asia/Makassar h0c Asia/Brunei h0d Asia/Kuching h0e Asia/Ulaanbaatar h0f Asia/Kuala_Lumpur h0g Asia/Choibalsan h0h Asia/Shanghai h0i Asia/Macau h0j Asia/Irkutsk h0k Asia/Hong_Kong h0l Asia/Manila h0m Australia/Perth h0n Etc/GMT-8 h0z Asia/Pyongyang h5a Australia/Eucla h8a Pacific/Palau i0a Asia/Khandyga i0b Asia/Seoul i0c Asia/Yakutsk i0d Asia/Dili i0e Asia/Chita i0f Asia/Jayapura i0g Asia/Tokyo i0h Etc/GMT-9 i0z Australia/Adelaide i5a Australia/Darwin i5b Australia/Broken_Hill i5c Australia/Brisbane k0a Pacific/Port_Moresby k0b Australia/Hobart k0c Australia/Sydney k0d Australia/Currie k0e Asia/Vladivostok k0f Australia/Lindeman k0g Australia/Melbourne k0h Asia/Ust-Nera k0i Antarctica/DumontDUrville k0j Pacific/Guam k0k Pacific/Chuuk k0l Etc/GMT-10 k0z Australia/Lord_Howe k5a Pacific/Bougainville l0a Pacific/Norfolk l0b Antarctica/Macquarie l0c Pacific/Kosrae l0d Asia/Sakhalin l0e Pacific/Noumea l0f Pacific/Guadalcanal l0g Asia/Magadan l0h Pacific/Efate l0i Asia/Srednekolymsk l0j Antarctica/Casey l0k Pacific/Pohnpei l0l Etc/GMT-11 l0z Pacific/Tarawa m0a Pacific/Nauru m0b Pacific/Majuro m0c Pacific/Fiji m0d Pacific/Kwajalein m0e Pacific/Wallis m0f Asia/Anadyr m0g Pacific/Wake m0h Pacific/Funafuti m0i Asia/Kamchatka m0j Pacific/Auckland m0k Etc/GMT-12 m0z Pacific/Tongatapu m1a Pacific/Fakaofo m1b Pacific/Enderbury m1c Pacific/Apia m1d Etc/GMT-13 m1z Pacific/Kiritimati m2a Etc/GMT-14 m2z Pacific/Chatham m8a Atlantic/Cape_Verde n0a Atlantic/Azores n0b America/Scoresbysund n0c Etc/GMT+1 n0z America/Noronha o0a Atlantic/South_Georgia o0b Etc/GMT+2 o0z America/Argentina/La_Rioja p0a America/Argentina/Catamarca p0b America/Montevideo p0c America/Argentina/Buenos_Aires p0d Antarctica/Rothera p0e America/Argentina/San_Juan p0f America/Sao_Paulo p0g America/Godthab p0h America/Araguaina p0i America/Argentina/Salta p0j America/Argentina/Mendoza p0k America/Santarem p0l America/Cayenne p0m America/Argentina/Tucuman p0n America/Argentina/Jujuy p0o Atlantic/Stanley p0p America/Argentina/Cordoba p0q America/Miquelon p0r America/Argentina/San_Luis p0s America/Belem p0t America/Maceio p0u America/Argentina/Ushuaia p0v America/Recife p0w America/Paramaribo p0x America/Bahia p0y Etc/GMT+3 p0z America/Fortaleza p1a America/Argentina/Rio_Gallegos p1b America/St_Johns p5a America/Blanc-Sablon q0a America/Grand_Turk q0b America/Goose_Bay q0c America/Glace_Bay q0d America/Guyana q0e America/Porto_Velho q0f America/Boa_Vista q0g America/Thule q0h America/Caracas q0i Atlantic/Bermuda q0j America/Martinique q0k America/Port_of_Spain q0l America/Campo_Grande q0m America/Halifax q0n America/Barbados q0o America/Moncton q0p America/Manaus q0q America/Santiago q0r America/La_Paz q0s America/Curacao q0t America/Santo_Domingo q0u America/Puerto_Rico q0v America/Asuncion q0w America/Cuiaba q0x Etc/GMT+4 q0z America/Cancun r0a America/Jamaica r0b America/Kentucky/Louisville r0c America/Rio_Branco r0d America/Indiana/Marengo r0e America/Kentucky/Monticello r0f America/Lima r0g America/Indiana/Winamac r0h America/Indiana/Indianapolis r0i America/New_York r0j America/Indiana/Vevay r0k America/Nipigon r0l America/Detroit r0m America/Guayaquil r0n America/Thunder_Bay r0o America/Panama r0p America/Iqaluit r0q America/Indiana/Vincennes r0r America/Bogota r0s America/Eirunepe r0t America/Atikokan r0u America/Indiana/Petersburg r0v America/Port-au-Prince r0w America/Nassau r0x America/Toronto r0y Etc/GMT+5 r0z America/Havana r1a America/Pangnirtung r1b America/Chicago s0a America/Resolute s0b America/Bahia_Banderas s0c America/North_Dakota/Beulah s0d America/Swift_Current s0e America/North_Dakota/Center s0f America/Winnipeg s0g America/El_Salvador s0h America/Indiana/Tell_City s0i America/Mexico_City s0j America/Costa_Rica s0k America/Monterrey s0l America/Tegucigalpa s0m America/Managua s0n America/Merida s0o America/Menominee s0p America/Rankin_Inlet s0q America/Belize s0r Pacific/Galapagos s0s America/Regina s0t America/Indiana/Knox s0u America/North_Dakota/New_Salem s0v Pacific/Easter s0w America/Rainy_River s0x America/Guatemala s0y Etc/GMT+6 s0z America/Matamoros s1a America/Edmonton t0a America/Chihuahua t0b America/Inuvik t0c America/Cambridge_Bay t0d America/Mazatlan t0e America/Hermosillo t0f America/Fort_Nelson t0g America/Boise t0h America/Yellowknife t0i America/Creston t0j America/Denver t0k America/Dawson_Creek t0l America/Phoenix t0m America/Ojinaga t0n Etc/GMT+7 t0z America/Tijuana u0a America/Los_Angeles u0b Pacific/Pitcairn u0c America/Vancouver u0d America/Whitehorse u0e America/Dawson u0f Etc/GMT+8 u0z America/Metlakatla v0a America/Anchorage v0b America/Juneau v0c America/Sitka v0d Pacific/Gambier v0e America/Yakutat v0f America/Nome v0g Etc/GMT+9 v0z Pacific/Marquesas v5a Pacific/Rarotonga w0a Pacific/Tahiti w0b Pacific/Honolulu w0c America/Adak w0d Etc/GMT+10 w0z Pacific/Pago_Pago x0a Pacific/Niue x0b Etc/GMT+11 x0z Etc/GMT+12 y0z Europe/Dublin z0a Africa/Abidjan z0b Atlantic/Faroe z0c Africa/Bissau z0d Atlantic/Madeira z0e Africa/Accra z0f Africa/Casablanca z0g Atlantic/Reykjavik z0h America/Danmarkshavn z0i Atlantic/Canary z0j Europe/Lisbon z0k Africa/Monrovia z0l Africa/El_Aaiun z0m Europe/London z0n Etc/UTC z0z Etc/GMT z0z
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate. But what about the tz designations (such as EDT), do we have a solution to that conundrum? On 2017-12-04 19:21, Michael Douglass wrote:
With a mapping table it doesn't matter what the id is. In fact any scheme for producing an id that is reversible or ordered in any way will lead to people using that then complaining down the road if you do something that "breaks" their code.
I'd suggest writing a small routine to create an 8 character random base64 id and get a new random id for each new zone. (I'd suggest a uuid but they're bulky).
Then create a legacy-mappings.txt file to map all the current names and aliases on to the new id - then we're sort of done.
I'd suggest a simple increasing sequence but you can guarantee that somebody would use it as an index even if told not to.
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
On 12/4/17 19:05, J Andrew Lipscomb wrote:
Le 4 déc. 2017 à 18:18, Michael Douglass <mikeadouglass@gmail.com> a écrit : Exactly - that's why I said opaque I just came up with a system I think is opaque enough while still maintaining a bit of useful information in the id: First up, it goes with the letter-digit-letter format.
The first letter represents the (lower) GMT offset of the zone in military format. (This represents the one real flaw I see: a zone’s proper letter can change if it adopts something on the order of year-round daylight savings time.)
The digit is usually 0. It changes in the following cases: 3 would indicate a +:15 zone if there were any, 5 is a +:30 zone, and 8 is a +:45 zone. 1 is used with M (normally +12) to indicate +13, and M2 similarly indicates +14. 1 is also used with other letters when the 0 range overflows.
The second letter is meaningless UNLESS it is Z. Z indicates a non-geographic time zone (the Etc/ series of indicators).
The list I just randomized, presented in order of newID:
Africa/Ndjamena a0a Africa/Tunis a0b Europe/Gibraltar a0c Europe/Monaco a0d Europe/Oslo a0e Europe/Warsaw a0f Europe/Zurich a0g Europe/Madrid a0h Europe/Copenhagen a0i Europe/Brussels a0j Europe/Malta a0k Europe/Andorra a0l Africa/Algiers a0m Europe/Paris a0n Europe/Amsterdam a0o Europe/Luxembourg a0p Africa/Ceuta a0q Europe/Tirane a0r Europe/Vienna a0s Europe/Belgrade a0t Europe/Budapest a0u Europe/Prague a0v Europe/Rome a0w Africa/Lagos a0x Europe/Stockholm a0y Etc/GMT-1 a0z Asia/Beirut b0a Europe/Bucharest b0b Europe/Riga b0c Africa/Khartoum b0d Asia/Damascus b0e Africa/Windhoek b0f Europe/Tallinn b0g Asia/Hebron b0h Africa/Maputo b0i Europe/Athens b0j Europe/Kiev b0k Europe/Sofia b0l Africa/Johannesburg b0m Europe/Chisinau b0n Europe/Zaporozhye b0o Asia/Famagusta b0p Asia/Nicosia b0q Africa/Tripoli b0r Europe/Uzhgorod b0s Asia/Jerusalem b0t Africa/Cairo b0u Asia/Amman b0v Asia/Gaza b0w Europe/Helsinki b0x Europe/Kaliningrad b0y Etc/GMT-2 b0z Europe/Vilnius b1a Europe/Minsk c0a Europe/Kirov c0b Africa/Nairobi c0c Antarctica/Syowa c0d Asia/Baghdad c0e Asia/Riyadh c0f Asia/Qatar c0g Europe/Istanbul c0h Africa/Juba c0i Europe/Moscow c0j Europe/Volgograd c0k Etc/GMT-3 c0z Asia/Tehran c5a Asia/Tbilisi d0a Europe/Saratov d0b Asia/Dubai d0c Europe/Samara d0d Indian/Reunion d0e Europe/Astrakhan d0f Indian/Mahe d0g Asia/Baku d0h Europe/Ulyanovsk d0i Asia/Yerevan d0j Indian/Mauritius d0k Etc/GMT-4 d0z Asia/Kabul d5a Asia/Samarkand e0a Asia/Aqtobe e0b Asia/Oral e0c Asia/Dushanbe e0d Asia/Karachi e0e Asia/Aqtau e0f Indian/Kerguelen e0g Asia/Yekaterinburg e0h Asia/Ashgabat e0i Asia/Tashkent e0j Antarctica/Mawson e0k Asia/Atyrau e0l Indian/Maldives e0m Etc/GMT-5 e0z Asia/Colombo e5a Asia/Kathmandu e8a Asia/Omsk f0a Asia/Dhaka f0b Antarctica/Vostok f0c Asia/Bishkek f0d Asia/Almaty f0e Asia/Thimphu f0f Asia/Urumqi f0g Asia/Qyzylorda f0h Indian/Chagos f0i Etc/GMT-6 f0z Asia/Yangon f5a Indian/Cocos f5b Asia/Pontianak g0a Asia/Tomsk g0b Asia/Bangkok g0c Asia/Hovd g0d Asia/Novokuznetsk g0e Asia/Jakarta g0f Asia/Krasnoyarsk g0g Antarctica/Davis g0h Asia/Barnaul g0i Asia/Novosibirsk g0j Indian/Christmas g0k Asia/Ho_Chi_Minh g0l Etc/GMT-7 g0z Asia/Singapore h0a Asia/Taipei h0b Asia/Makassar h0c Asia/Brunei h0d Asia/Kuching h0e Asia/Ulaanbaatar h0f Asia/Kuala_Lumpur h0g Asia/Choibalsan h0h Asia/Shanghai h0i Asia/Macau h0j Asia/Irkutsk h0k Asia/Hong_Kong h0l Asia/Manila h0m Australia/Perth h0n Etc/GMT-8 h0z Asia/Pyongyang h5a Australia/Eucla h8a Pacific/Palau i0a Asia/Khandyga i0b Asia/Seoul i0c Asia/Yakutsk i0d Asia/Dili i0e Asia/Chita i0f Asia/Jayapura i0g Asia/Tokyo i0h Etc/GMT-9 i0z Australia/Adelaide i5a Australia/Darwin i5b Australia/Broken_Hill i5c Australia/Brisbane k0a Pacific/Port_Moresby k0b Australia/Hobart k0c Australia/Sydney k0d Australia/Currie k0e Asia/Vladivostok k0f Australia/Lindeman k0g Australia/Melbourne k0h Asia/Ust-Nera k0i Antarctica/DumontDUrville k0j Pacific/Guam k0k Pacific/Chuuk k0l Etc/GMT-10 k0z Australia/Lord_Howe k5a Pacific/Bougainville l0a Pacific/Norfolk l0b Antarctica/Macquarie l0c Pacific/Kosrae l0d Asia/Sakhalin l0e Pacific/Noumea l0f Pacific/Guadalcanal l0g Asia/Magadan l0h Pacific/Efate l0i Asia/Srednekolymsk l0j Antarctica/Casey l0k Pacific/Pohnpei l0l Etc/GMT-11 l0z Pacific/Tarawa m0a Pacific/Nauru m0b Pacific/Majuro m0c Pacific/Fiji m0d Pacific/Kwajalein m0e Pacific/Wallis m0f Asia/Anadyr m0g Pacific/Wake m0h Pacific/Funafuti m0i Asia/Kamchatka m0j Pacific/Auckland m0k Etc/GMT-12 m0z Pacific/Tongatapu m1a Pacific/Fakaofo m1b Pacific/Enderbury m1c Pacific/Apia m1d Etc/GMT-13 m1z Pacific/Kiritimati m2a Etc/GMT-14 m2z Pacific/Chatham m8a Atlantic/Cape_Verde n0a Atlantic/Azores n0b America/Scoresbysund n0c Etc/GMT+1 n0z America/Noronha o0a Atlantic/South_Georgia o0b Etc/GMT+2 o0z America/Argentina/La_Rioja p0a America/Argentina/Catamarca p0b America/Montevideo p0c America/Argentina/Buenos_Aires p0d Antarctica/Rothera p0e America/Argentina/San_Juan p0f America/Sao_Paulo p0g America/Godthab p0h America/Araguaina p0i America/Argentina/Salta p0j America/Argentina/Mendoza p0k America/Santarem p0l America/Cayenne p0m America/Argentina/Tucuman p0n America/Argentina/Jujuy p0o Atlantic/Stanley p0p America/Argentina/Cordoba p0q America/Miquelon p0r America/Argentina/San_Luis p0s America/Belem p0t America/Maceio p0u America/Argentina/Ushuaia p0v America/Recife p0w America/Paramaribo p0x America/Bahia p0y Etc/GMT+3 p0z America/Fortaleza p1a America/Argentina/Rio_Gallegos p1b America/St_Johns p5a America/Blanc-Sablon q0a America/Grand_Turk q0b America/Goose_Bay q0c America/Glace_Bay q0d America/Guyana q0e America/Porto_Velho q0f America/Boa_Vista q0g America/Thule q0h America/Caracas q0i Atlantic/Bermuda q0j America/Martinique q0k America/Port_of_Spain q0l America/Campo_Grande q0m America/Halifax q0n America/Barbados q0o America/Moncton q0p America/Manaus q0q America/Santiago q0r America/La_Paz q0s America/Curacao q0t America/Santo_Domingo q0u America/Puerto_Rico q0v America/Asuncion q0w America/Cuiaba q0x Etc/GMT+4 q0z America/Cancun r0a America/Jamaica r0b America/Kentucky/Louisville r0c America/Rio_Branco r0d America/Indiana/Marengo r0e America/Kentucky/Monticello r0f America/Lima r0g America/Indiana/Winamac r0h America/Indiana/Indianapolis r0i America/New_York r0j America/Indiana/Vevay r0k America/Nipigon r0l America/Detroit r0m America/Guayaquil r0n America/Thunder_Bay r0o America/Panama r0p America/Iqaluit r0q America/Indiana/Vincennes r0r America/Bogota r0s America/Eirunepe r0t America/Atikokan r0u America/Indiana/Petersburg r0v America/Port-au-Prince r0w America/Nassau r0x America/Toronto r0y Etc/GMT+5 r0z America/Havana r1a America/Pangnirtung r1b America/Chicago s0a America/Resolute s0b America/Bahia_Banderas s0c America/North_Dakota/Beulah s0d America/Swift_Current s0e America/North_Dakota/Center s0f America/Winnipeg s0g America/El_Salvador s0h America/Indiana/Tell_City s0i America/Mexico_City s0j America/Costa_Rica s0k America/Monterrey s0l America/Tegucigalpa s0m America/Managua s0n America/Merida s0o America/Menominee s0p America/Rankin_Inlet s0q America/Belize s0r Pacific/Galapagos s0s America/Regina s0t America/Indiana/Knox s0u America/North_Dakota/New_Salem s0v Pacific/Easter s0w America/Rainy_River s0x America/Guatemala s0y Etc/GMT+6 s0z America/Matamoros s1a America/Edmonton t0a America/Chihuahua t0b America/Inuvik t0c America/Cambridge_Bay t0d America/Mazatlan t0e America/Hermosillo t0f America/Fort_Nelson t0g America/Boise t0h America/Yellowknife t0i America/Creston t0j America/Denver t0k America/Dawson_Creek t0l America/Phoenix t0m America/Ojinaga t0n Etc/GMT+7 t0z America/Tijuana u0a America/Los_Angeles u0b Pacific/Pitcairn u0c America/Vancouver u0d America/Whitehorse u0e America/Dawson u0f Etc/GMT+8 u0z America/Metlakatla v0a America/Anchorage v0b America/Juneau v0c America/Sitka v0d Pacific/Gambier v0e America/Yakutat v0f America/Nome v0g Etc/GMT+9 v0z Pacific/Marquesas v5a Pacific/Rarotonga w0a Pacific/Tahiti w0b Pacific/Honolulu w0c America/Adak w0d Etc/GMT+10 w0z Pacific/Pago_Pago x0a Pacific/Niue x0b Etc/GMT+11 x0z Etc/GMT+12 y0z Europe/Dublin z0a Africa/Abidjan z0b Atlantic/Faroe z0c Africa/Bissau z0d Atlantic/Madeira z0e Africa/Accra z0f Africa/Casablanca z0g Atlantic/Reykjavik z0h America/Danmarkshavn z0i Atlantic/Canary z0j Europe/Lisbon z0k Africa/Monrovia z0l Africa/El_Aaiun z0m Europe/London z0n Etc/UTC z0z Etc/GMT z0z
--
On 12/4/17 19:38, David Patte ₯ wrote:
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate.
But what about the tz designations (such as EDT), do we have a solution to that conundrum? I think under such as scheme the differentiation between names and aliases disappears. They are all names mapped onto a unique tzid, so America/NewYork and US/Eastern would refer to the same tzid.
On 2017-12-04 19:21, Michael Douglass wrote:
With a mapping table it doesn't matter what the id is. In fact any scheme for producing an id that is reversible or ordered in any way will lead to people using that then complaining down the road if you do something that "breaks" their code.
I'd suggest writing a small routine to create an 8 character random base64 id and get a new random id for each new zone. (I'd suggest a uuid but they're bulky).
Then create a legacy-mappings.txt file to map all the current names and aliases on to the new id - then we're sort of done.
I'd suggest a simple increasing sequence but you can guarantee that somebody would use it as an index even if told not to.
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
On 12/4/17 19:05, J Andrew Lipscomb wrote:
Le 4 déc. 2017 à 18:18, Michael Douglass <mikeadouglass@gmail.com> a écrit : Exactly - that's why I said opaque I just came up with a system I think is opaque enough while still maintaining a bit of useful information in the id: First up, it goes with the letter-digit-letter format.
The first letter represents the (lower) GMT offset of the zone in military format. (This represents the one real flaw I see: a zone’s proper letter can change if it adopts something on the order of year-round daylight savings time.)
The digit is usually 0. It changes in the following cases: 3 would indicate a +:15 zone if there were any, 5 is a +:30 zone, and 8 is a +:45 zone. 1 is used with M (normally +12) to indicate +13, and M2 similarly indicates +14. 1 is also used with other letters when the 0 range overflows.
The second letter is meaningless UNLESS it is Z. Z indicates a non-geographic time zone (the Etc/ series of indicators).
The list I just randomized, presented in order of newID:
Africa/Ndjamena a0a Africa/Tunis a0b Europe/Gibraltar a0c Europe/Monaco a0d Europe/Oslo a0e Europe/Warsaw a0f Europe/Zurich a0g Europe/Madrid a0h Europe/Copenhagen a0i Europe/Brussels a0j Europe/Malta a0k Europe/Andorra a0l Africa/Algiers a0m Europe/Paris a0n Europe/Amsterdam a0o Europe/Luxembourg a0p Africa/Ceuta a0q Europe/Tirane a0r Europe/Vienna a0s Europe/Belgrade a0t Europe/Budapest a0u Europe/Prague a0v Europe/Rome a0w Africa/Lagos a0x Europe/Stockholm a0y Etc/GMT-1 a0z Asia/Beirut b0a Europe/Bucharest b0b Europe/Riga b0c Africa/Khartoum b0d Asia/Damascus b0e Africa/Windhoek b0f Europe/Tallinn b0g Asia/Hebron b0h Africa/Maputo b0i Europe/Athens b0j Europe/Kiev b0k Europe/Sofia b0l Africa/Johannesburg b0m Europe/Chisinau b0n Europe/Zaporozhye b0o Asia/Famagusta b0p Asia/Nicosia b0q Africa/Tripoli b0r Europe/Uzhgorod b0s Asia/Jerusalem b0t Africa/Cairo b0u Asia/Amman b0v Asia/Gaza b0w Europe/Helsinki b0x Europe/Kaliningrad b0y Etc/GMT-2 b0z Europe/Vilnius b1a Europe/Minsk c0a Europe/Kirov c0b Africa/Nairobi c0c Antarctica/Syowa c0d Asia/Baghdad c0e Asia/Riyadh c0f Asia/Qatar c0g Europe/Istanbul c0h Africa/Juba c0i Europe/Moscow c0j Europe/Volgograd c0k Etc/GMT-3 c0z Asia/Tehran c5a Asia/Tbilisi d0a Europe/Saratov d0b Asia/Dubai d0c Europe/Samara d0d Indian/Reunion d0e Europe/Astrakhan d0f Indian/Mahe d0g Asia/Baku d0h Europe/Ulyanovsk d0i Asia/Yerevan d0j Indian/Mauritius d0k Etc/GMT-4 d0z Asia/Kabul d5a Asia/Samarkand e0a Asia/Aqtobe e0b Asia/Oral e0c Asia/Dushanbe e0d Asia/Karachi e0e Asia/Aqtau e0f Indian/Kerguelen e0g Asia/Yekaterinburg e0h Asia/Ashgabat e0i Asia/Tashkent e0j Antarctica/Mawson e0k Asia/Atyrau e0l Indian/Maldives e0m Etc/GMT-5 e0z Asia/Colombo e5a Asia/Kathmandu e8a Asia/Omsk f0a Asia/Dhaka f0b Antarctica/Vostok f0c Asia/Bishkek f0d Asia/Almaty f0e Asia/Thimphu f0f Asia/Urumqi f0g Asia/Qyzylorda f0h Indian/Chagos f0i Etc/GMT-6 f0z Asia/Yangon f5a Indian/Cocos f5b Asia/Pontianak g0a Asia/Tomsk g0b Asia/Bangkok g0c Asia/Hovd g0d Asia/Novokuznetsk g0e Asia/Jakarta g0f Asia/Krasnoyarsk g0g Antarctica/Davis g0h Asia/Barnaul g0i Asia/Novosibirsk g0j Indian/Christmas g0k Asia/Ho_Chi_Minh g0l Etc/GMT-7 g0z Asia/Singapore h0a Asia/Taipei h0b Asia/Makassar h0c Asia/Brunei h0d Asia/Kuching h0e Asia/Ulaanbaatar h0f Asia/Kuala_Lumpur h0g Asia/Choibalsan h0h Asia/Shanghai h0i Asia/Macau h0j Asia/Irkutsk h0k Asia/Hong_Kong h0l Asia/Manila h0m Australia/Perth h0n Etc/GMT-8 h0z Asia/Pyongyang h5a Australia/Eucla h8a Pacific/Palau i0a Asia/Khandyga i0b Asia/Seoul i0c Asia/Yakutsk i0d Asia/Dili i0e Asia/Chita i0f Asia/Jayapura i0g Asia/Tokyo i0h Etc/GMT-9 i0z Australia/Adelaide i5a Australia/Darwin i5b Australia/Broken_Hill i5c Australia/Brisbane k0a Pacific/Port_Moresby k0b Australia/Hobart k0c Australia/Sydney k0d Australia/Currie k0e Asia/Vladivostok k0f Australia/Lindeman k0g Australia/Melbourne k0h Asia/Ust-Nera k0i Antarctica/DumontDUrville k0j Pacific/Guam k0k Pacific/Chuuk k0l Etc/GMT-10 k0z Australia/Lord_Howe k5a Pacific/Bougainville l0a Pacific/Norfolk l0b Antarctica/Macquarie l0c Pacific/Kosrae l0d Asia/Sakhalin l0e Pacific/Noumea l0f Pacific/Guadalcanal l0g Asia/Magadan l0h Pacific/Efate l0i Asia/Srednekolymsk l0j Antarctica/Casey l0k Pacific/Pohnpei l0l Etc/GMT-11 l0z Pacific/Tarawa m0a Pacific/Nauru m0b Pacific/Majuro m0c Pacific/Fiji m0d Pacific/Kwajalein m0e Pacific/Wallis m0f Asia/Anadyr m0g Pacific/Wake m0h Pacific/Funafuti m0i Asia/Kamchatka m0j Pacific/Auckland m0k Etc/GMT-12 m0z Pacific/Tongatapu m1a Pacific/Fakaofo m1b Pacific/Enderbury m1c Pacific/Apia m1d Etc/GMT-13 m1z Pacific/Kiritimati m2a Etc/GMT-14 m2z Pacific/Chatham m8a Atlantic/Cape_Verde n0a Atlantic/Azores n0b America/Scoresbysund n0c Etc/GMT+1 n0z America/Noronha o0a Atlantic/South_Georgia o0b Etc/GMT+2 o0z America/Argentina/La_Rioja p0a America/Argentina/Catamarca p0b America/Montevideo p0c America/Argentina/Buenos_Aires p0d Antarctica/Rothera p0e America/Argentina/San_Juan p0f America/Sao_Paulo p0g America/Godthab p0h America/Araguaina p0i America/Argentina/Salta p0j America/Argentina/Mendoza p0k America/Santarem p0l America/Cayenne p0m America/Argentina/Tucuman p0n America/Argentina/Jujuy p0o Atlantic/Stanley p0p America/Argentina/Cordoba p0q America/Miquelon p0r America/Argentina/San_Luis p0s America/Belem p0t America/Maceio p0u America/Argentina/Ushuaia p0v America/Recife p0w America/Paramaribo p0x America/Bahia p0y Etc/GMT+3 p0z America/Fortaleza p1a America/Argentina/Rio_Gallegos p1b America/St_Johns p5a America/Blanc-Sablon q0a America/Grand_Turk q0b America/Goose_Bay q0c America/Glace_Bay q0d America/Guyana q0e America/Porto_Velho q0f America/Boa_Vista q0g America/Thule q0h America/Caracas q0i Atlantic/Bermuda q0j America/Martinique q0k America/Port_of_Spain q0l America/Campo_Grande q0m America/Halifax q0n America/Barbados q0o America/Moncton q0p America/Manaus q0q America/Santiago q0r America/La_Paz q0s America/Curacao q0t America/Santo_Domingo q0u America/Puerto_Rico q0v America/Asuncion q0w America/Cuiaba q0x Etc/GMT+4 q0z America/Cancun r0a America/Jamaica r0b America/Kentucky/Louisville r0c America/Rio_Branco r0d America/Indiana/Marengo r0e America/Kentucky/Monticello r0f America/Lima r0g America/Indiana/Winamac r0h America/Indiana/Indianapolis r0i America/New_York r0j America/Indiana/Vevay r0k America/Nipigon r0l America/Detroit r0m America/Guayaquil r0n America/Thunder_Bay r0o America/Panama r0p America/Iqaluit r0q America/Indiana/Vincennes r0r America/Bogota r0s America/Eirunepe r0t America/Atikokan r0u America/Indiana/Petersburg r0v America/Port-au-Prince r0w America/Nassau r0x America/Toronto r0y Etc/GMT+5 r0z America/Havana r1a America/Pangnirtung r1b America/Chicago s0a America/Resolute s0b America/Bahia_Banderas s0c America/North_Dakota/Beulah s0d America/Swift_Current s0e America/North_Dakota/Center s0f America/Winnipeg s0g America/El_Salvador s0h America/Indiana/Tell_City s0i America/Mexico_City s0j America/Costa_Rica s0k America/Monterrey s0l America/Tegucigalpa s0m America/Managua s0n America/Merida s0o America/Menominee s0p America/Rankin_Inlet s0q America/Belize s0r Pacific/Galapagos s0s America/Regina s0t America/Indiana/Knox s0u America/North_Dakota/New_Salem s0v Pacific/Easter s0w America/Rainy_River s0x America/Guatemala s0y Etc/GMT+6 s0z America/Matamoros s1a America/Edmonton t0a America/Chihuahua t0b America/Inuvik t0c America/Cambridge_Bay t0d America/Mazatlan t0e America/Hermosillo t0f America/Fort_Nelson t0g America/Boise t0h America/Yellowknife t0i America/Creston t0j America/Denver t0k America/Dawson_Creek t0l America/Phoenix t0m America/Ojinaga t0n Etc/GMT+7 t0z America/Tijuana u0a America/Los_Angeles u0b Pacific/Pitcairn u0c America/Vancouver u0d America/Whitehorse u0e America/Dawson u0f Etc/GMT+8 u0z America/Metlakatla v0a America/Anchorage v0b America/Juneau v0c America/Sitka v0d Pacific/Gambier v0e America/Yakutat v0f America/Nome v0g Etc/GMT+9 v0z Pacific/Marquesas v5a Pacific/Rarotonga w0a Pacific/Tahiti w0b Pacific/Honolulu w0c America/Adak w0d Etc/GMT+10 w0z Pacific/Pago_Pago x0a Pacific/Niue x0b Etc/GMT+11 x0z Etc/GMT+12 y0z Europe/Dublin z0a Africa/Abidjan z0b Atlantic/Faroe z0c Africa/Bissau z0d Atlantic/Madeira z0e Africa/Accra z0f Africa/Casablanca z0g Atlantic/Reykjavik z0h America/Danmarkshavn z0i Atlantic/Canary z0j Europe/Lisbon z0k Africa/Monrovia z0l Africa/El_Aaiun z0m Europe/London z0n Etc/UTC z0z Etc/GMT z0z
On Dec 4, 2017, at 6:26 PM, Michael Douglass <mikeadouglass@gmail.com> wrote:
On 12/4/17 19:38, David Patte ₯ wrote:
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate.
But what about the tz designations (such as EDT), do we have a solution to that conundrum? I think under such as scheme the differentiation between names and aliases disappears. They are all names mapped onto a unique tzid, so America/NewYork and US/Eastern would refer to the same tzid.
As I pointed out in an earlier email in this thread, the "tz designations (such as EDT)" are separate items from tzids (such as America/New_York and US/Eastern). tzids are names for tzdb regions, with every tzdb region having a tzid (and some aliases) that refer to it, and every tzid referring to one and only one tzdb region. Tz designations are just things that are shown in times displayed to humans, and do *not* refer to a particular tzdb region and cannot always be used to uniquely identify a tzdb region (for example, does "CST" refer to America/Chicago, America/Indiana/Indianapolis, America/Winnipeg, etc.?) So nothing done about tzids will have any effect whatsoever on tz designations or on the conundrum in question, namely "what to do about tz designations that the tzdb maintainers invented in order that, at certain times in certain tzdb regions, UN*X/POSIX API implementations using the tzdb could provide a tz designation to use at those particular times".
On 4 December 2017 at 19:21, Michael Douglass <mikeadouglass@gmail.com> wrote:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
On 4 December 2017 at 19:38, David Patte ₯ <dpatte@relativedata.com> wrote:
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate.
Except it likely doesn't make anything better for maintenance. With strictly opaque IDs, this project would still need to track the approximate geographical scope of each identifier in much the same manner as we already do, so as to aid in identifying when zone splits are necessary, etc. Currently, that task is fairly clear with human-readable IDs identifying a city and commentary filling in the details where necessary. This is, of course, only done to roughly record the general contours of zones so we know how to update them, not any attempt at recording precise borders. Indeed, it is (or should be) well-known to this list that our IDs can be considered to overlap geographically in several cases, and that these are often the most geopolitically divisive cases. Replacing IDs with opaque strings would complicate this maintenance somewhat, although that complication could be mitigated by further standardization our geographical commentary to assist in maintenance. However, at that point, the questions don't become "why doesn't Important City have its own ID?" but rather "why isn't Important City in the commentary for this ID?" or "why is Important City listed in the commentary for the 'wrong' ID?" And so, just like now, we'd continue recording the existence of disputes and the like with care, while not taking any stance and pushing back on requests to conform to any particular side. So ultimately, we'd get different questions, sure… but I'm entirely unconvinced they'd be any fewer or any less political. Frankly, I've long thought the whole idea of fully-opaque IDs is a non-starter, and I'd much rather see our collective efforts spent elsewhere. Time zones are inherently geopolitical in nature; we can certainly work to minimize the impact of geopolitics on this project, but we cannot eliminate it entirely, and efforts to do so are fruitless. But what about the tz designations (such as EDT), do we have a solution to
that conundrum?
In the past, there was a proposal to simply eliminate them all, and use some static string like "zzz", "-", "local", or "". But this has similar problems as above, since it is impossible to identify the source zone or corresponding UTC timepoint. The numeric %z format that many zones have recently moved to is marginally better in the one regard, but we've seen that that has had (the expected) knock-on effects caused by (mis)use of the "abbreviation" field when heuristics fail to identify the correct source zone from the incomplete information. Honestly, if it weren't for character limitations, the "abbreviation" field should probably just return something akin to "<-05>America/New_York" for all zones at all times, leaving strings like "EST" (in English) or "HNE" (in French) to localization projects like CLDR. This would have the advantage of providing everything needed to reconstruct the UTC timepoint and identify the source zone (given a specific version of this project, at least), but the distinct disadvantage of being a bit unwieldy. -- Tim Parenti
On 12/4/17 23:02, Tim Parenti wrote:
On 4 December 2017 at 19:21, Michael Douglass <mikeadouglass@gmail.com <mailto:mikeadouglass@gmail.com>> wrote:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
On 4 December 2017 at 19:38, David Patte ₯ <dpatte@relativedata.com <mailto:dpatte@relativedata.com>> wrote:
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate.
Except it likely doesn't make anything better for maintenance. With strictly opaque IDs, this project would still need to track the approximate geographical scope of each identifier in much the same manner as we already do, so as to aid in identifying when zone splits are necessary, etc. Currently, that task is fairly clear with human-readable IDs identifying a city and commentary filling in the details where necessary. This is, of course, only done to roughly record the general contours of zones so we know how to update them, not any attempt at recording precise borders. Indeed, it is (or should be) well-known to this list that our IDs can be considered to overlap geographically in several cases, and that these are often the most geopolitically divisive cases.
Replacing IDs with opaque strings would complicate this maintenance somewhat, although that complication could be mitigated by further standardization our geographical commentary to assist in maintenance. However, at that point, the questions don't become "why doesn't Important City have its own ID?" but rather "why isn't Important City in the commentary for this ID?" or "why is Important City listed in the commentary for the 'wrong' ID?" And so, just like now, we'd continue recording the existence of disputes and the like with care, while not taking any stance and pushing back on requests to conform to any particular side. So ultimately, we'd get different questions, sure… but I'm entirely unconvinced they'd be any fewer or any less political.
Frankly, I've long thought the whole idea of fully-opaque IDs is a non-starter, and I'd much rather see our collective efforts spent elsewhere. Time zones are inherently geopolitical in nature; we can certainly work to minimize the impact of geopolitics on this project, but we cannot eliminate it entirely, and efforts to do so are fruitless. The names unfortunately are political - like it or not. Apparently there are organizations that cannot use this data for that reason. Using the current naming as an internal reference is fine but the timezones themselves should have an opaque id that doesn't cause problems. CLDR provides localization data - we just need a new key. You can be (almost) apolitical when all you do is record the use of time in certain geographic regions. You can't be when you assign disputed names to them. People will assign motive to your actions whatever your intentions.
But what about the tz designations (such as EDT), do we have a solution to that conundrum?
In the past, there was a proposal to simply eliminate them all, and use some static string like "zzz", "-", "local", or "". But this has similar problems as above, since it is impossible to identify the source zone or corresponding UTC timepoint. The numeric %z format that many zones have recently moved to is marginally better in the one regard, but we've seen that that has had (the expected) knock-on effects caused by (mis)use of the "abbreviation" field when heuristics fail to identify the correct source zone from the incomplete information.
Honestly, if it weren't for character limitations, the "abbreviation" field should probably just return something akin to "<-05>America/New_York" for all zones at all times, leaving strings like "EST" (in English) or "HNE" (in French) to localization projects like CLDR. This would have the advantage of providing everything needed to reconstruct the UTC timepoint and identify the source zone (given a specific version of this project, at least), but the distinct disadvantage of being a bit unwieldy.
-- Tim Parenti
On Dec 4, 2017, at 8:16 PM, Michael Douglass <mikeadouglass@gmail.com> wrote:
The names unfortunately are political - like it or not. Apparently there are organizations that cannot use this data for that reason. Using the current naming as an internal reference is fine but the timezones themselves should have an opaque id that doesn't cause problems. CLDR provides localization data - we just need a new key.
The CLDR provides localization data for timezone abbreviations (and timezone long names) in the <timeZoneNames> sections of main/{2-letter-language-code}.xml, in the list of <zone type="XXX"> and <metazone type="XXX"> items. The XXX's for <zone> are tzdb region IDs, and if we changed the tzdb region IDs, those would have to change, but the XXX's for <metazone> aren't tzdb region IDs, and wouldn't have to change if we changed tzdb region IDs.
On Dec 4, 2017, at 8:02 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 4 December 2017 at 19:21, Michael Douglass <mikeadouglass@gmail.com> wrote:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
On 4 December 2017 at 19:38, David Patte ₯ <dpatte@relativedata.com> wrote:
Using such a scheme, a database such as geonames would then map a location to the tz id (as it does now), defering political arguments to geonames, and removing them from this list. It seems appropriate.
Except it likely doesn't make anything better for maintenance. With strictly opaque IDs, this project would still need to track the approximate geographical scope of each identifier in much the same manner as we already do, so as to aid in identifying when zone splits are necessary, etc. Currently, that task is fairly clear with human-readable IDs identifying a city and commentary filling in the details where necessary. This is, of course, only done to roughly record the general contours of zones so we know how to update them, not any attempt at recording precise borders. Indeed, it is (or should be) well-known to this list that our IDs can be considered to overlap geographically in several cases, and that these are often the most geopolitically divisive cases.
Replacing IDs with opaque strings would complicate this maintenance somewhat,
Because, if, for example, some US state currently in the Eastern time zone near its Western edge, and having obeyed the standard America/New_York daylight savings time transition rules since 1970, were to decide to move to the Central time zone - or to move the western half to the Central time zone - it'd be easier to remember that this means "the borders of tzdb region America/New_York change" than to remember that this means "the borders of tzdb region Q7F9 change"?
although that complication could be mitigated by further standardization our geographical commentary to assist in maintenance. However, at that point, the questions don't become "why doesn't Important City have its own ID?"
Do you mean people are asking "why doesn't this tzdb region have multiple IDs for all its Important Cities?" or do you mean they're asking "why don't all these Important Cities have their own tzdb regions and therefore have their own IDs"?
but rather "why isn't Important City in the commentary for this ID?"
For every tzdb region, is there some small number of Important Cities such that 1) it's small enough that we could list *all* of them in the commentary for the region and 2) there aren't any cities for which we'll still get "why isn't Important City in the commentary for this ID?" and can't somewhat reasonably reply "that's not really an Important Enough City, sorry"?
or "why is Important City listed in the commentary for the 'wrong' ID?"
So you're thinking of a case here where the tzdb region to which a city would belong is disputed (probably due to the political status of the city being disputed)?
But what about the tz designations (such as EDT), do we have a solution to that conundrum?
In the past, there was a proposal to simply eliminate them all, and use some static string like "zzz", "-", "local", or "". But this has similar problems as above, since it is impossible to identify the source zone or corresponding UTC timepoint. The numeric %z format that many zones have recently moved to is marginally better in the one regard, but we've seen that that has had (the expected) knock-on effects caused by (mis)use of the "abbreviation" field when heuristics fail to identify the correct source zone from the incomplete information.
Honestly, if it weren't for character limitations, the "abbreviation" field should probably just return something akin to "<-05>America/New_York" for all zones at all times, leaving strings like "EST" (in English) or "HNE" (in French) to localization projects like CLDR. This would have the advantage of providing everything needed to reconstruct the UTC timepoint and identify the source zone (given a specific version of this project, at least), but the distinct disadvantage of being a bit unwieldy.
By "character limitations" I assume you're referring to the limitations imposed by http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html section 8.3 "Other Environment Variables", combined with the fact that a lot of time zone code on POSIX-compliant systems, and trying-at-least-to-be-reasonably-compatible-with-POSIX systems, uses the information in the tzdb to provide time zone abbreviations, and that rather a lot of software would be Rudely Surprised if we provided an offset from UTC and a tzdb region ID rather than an abbreviation of the form that people expect that that UN*Xes have provided for a few decades. (I think the "combined with" part is actually the relevant part here; the POSIX specification just codifies what UN*X developers, and users of UN*Xes, have come to expect.) Perhaps what we *should* do is provide, in addition to UN*X-style abbreviations, "metazone" names, as per http://cldr.unicode.org/translation/timezones so that software can, given a tzdb region ID and a date/time, find out the metazone for that region at that date and time from the tzdb data, and then look up that metazone in the CLDR and find the time zone long name and abbreviation that should be used, in a given locale, for that date and time. If there *is* no metazone, as would be the case in, for example, the US from February 9, 1942 to September 30, 1945 (there's no metazone I can see for "war time"), we wouldn't supply one, and that software would have to fall back on the abbreviation we supply. We'd still have to supply abbreviations for the benefit of software that *doesn't* use the CLDR as well as for "time zones" with no metazone (and, at least for some period of time, the CLDR would still have to supply supplemental/metaZones.xml, duplicating information from the tzdb, as it might be used on systems that *don't* supply the metazone).
<<On Mon, 4 Dec 2017 23:02:39 -0500, Tim Parenti <tim@timtimeonline.com> said:
Frankly, I've long thought the whole idea of fully-opaque IDs is a non-starter, and I'd much rather see our collective efforts spent elsewhere. Time zones are inherently geopolitical in nature; we can certainly work to minimize the impact of geopolitics on this project, but we cannot eliminate it entirely, and efforts to do so are fruitless.
+1 -GAWollman
The original reason for the latest discussion was actually precipitaed from a request of clarity into why Greenland time zone designator was changed from GST/WGST to -3. The original author said that he felt GST/WGST was in common usage. I believe the answer should have been that he should provide evidence that it is in common usage in Greenland, preferably documentation of what the Greenland government prefers for the designator. On 2017-12-05 15:17, Garrett Wollman wrote:
<<On Mon, 4 Dec 2017 23:02:39 -0500, Tim Parenti <tim@timtimeonline.com> said:
Frankly, I've long thought the whole idea of fully-opaque IDs is a non-starter, and I'd much rather see our collective efforts spent elsewhere. Time zones are inherently geopolitical in nature; we can certainly work to minimize the impact of geopolitics on this project, but we cannot eliminate it entirely, and efforts to do so are fruitless. +1
-GAWollman
--
On 5 December 2017 at 15:04, Guy Harris <guy@alum.mit.edu> wrote:
How about "use a command-line picker", e.g.
$ tzid "Dusseldorf" Europe/Berlin
So… what should `tzid "Disputed City"` return? This doesn't really do anything solve the (supposed) problem. On 5 December 2017 at 15:32, David Patte ₯ <dpatte@relativedata.com> wrote:
The original reason for the latest discussion was actually precipitaed from a request of clarity into why Greenland time zone designator was changed from GST/WGST to -3. The original author said that he felt GST/WGST was in common usage.
I believe the answer should have been that he should provide evidence that it is in common usage in Greenland, preferably documentation of what the Greenland government prefers for the designator.
To be fair, that was basically my original answer. ;) http://mm.icann.org/pipermail/tz/2017-December/025607.html -- Tim Parenti
On Dec 5, 2017, at 12:38 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 5 December 2017 at 15:04, Guy Harris <guy@alum.mit.edu> wrote:
How about "use a command-line picker", e.g.
$ tzid "Dusseldorf" Europe/Berlin
So… what should `tzid "Disputed City"` return? This doesn't really do anything solve the (supposed) problem.
To what problem are you referring when you speak of "*the* (supposed) problem"? Beijing, to pick a city that provokes complaints, is "disputed" in the sense that people complain that there's no "Asia/Beijing", but I'm unaware that there are any disputes as to which tzdb region it belongs in - as per my examples (several *not* chosen randomly :-)), "tzid Beijing" should print "Asia/Shanghai", even if that causes some residents of Beijing to whine about Shanghai being mentioned. For cities where there's a dispute over which rules apply, this is, in most if not all cases, probably a consequence of a dispute over which government is in charge of the city, i.e. a political dispute. *That's* the only case I see where "what should tzid return?" would not have an obvious answer.
David Patte ₯ <dpatte@relativedata.com> writes:
The original reason for the latest discussion was actually precipitaed from a request of clarity into why Greenland time zone designator was changed from GST/WGST to -3. The original author said that he felt GST/WGST was in common usage.
I think the abbreviations are a much different issue than the zone identifiers, and I'd personally love to see them go away completely (even ones like PDT). I know that's too radical to be practical, but those three or four character abbreviations are traps for the unwary. There aren't enough places to put disclaimers about them, people constantly assume they're unique when they're not, and I've found far, far too many buggy date parsers that try to extract meaning from them. Replacing as many of them as possible with simple offset indications or some other mostly meaningless string is a service to future programmers as far as I'm concerned. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
On 2017-12-05 20:18, Russ Allbery wrote:
David Patte ₯ <dpatte@relativedata.com> writes:
The original reason for the latest discussion was actually precipitaed from a request of clarity into why Greenland time zone designator was changed from WGT/WGST to -3. The original author said that he felt WGT/WGST was in common usage. I think the abbreviations are a much different issue than the zone identifiers, and I'd personally love to see them go away completely (even ones like PDT). I know that's too radical to be practical, but those three or four character abbreviations are traps for the unwary. There aren't enough places to put disclaimers about them, people constantly assume they're unique when they're not, and I've found far, far too many buggy date parsers that try to extract meaning from them. Replacing as many of them as possible with simple offset indications or some other mostly meaningless string is a service to future programmers as far as I'm concerned.
Just you wait to see what they come up with to generate the previous output! ;^> Assumptions about the importance to users of these historical artifacts, and bikeshed arguments about "compatibility" often prevail, when the appropriate input should be - it was made up and has been dropped - how much can you afford to pay to keep it around? People have compiled and used calendars for millenia, Gregorian calendars for over 250/400 years, standard time zones for over a century, summer daylight saving times for about a century, leap seconds for 45 years, and programmers still get simple things badly wrong, that could be easily tested and checked using suitable APIs or apps on the same system, or many other systems. The C and POSIX standards should have defined an opaque temporal type with access only via the API, and later an opaque calendrical type and API, perhaps optional, to extend this on hosted implementations. It's a benefit that tz handling is effectively opaque to most programmers. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:
On 2017-12-05 20:18, Russ Allbery wrote:
I know that's too radical to be practical, but those three or four character abbreviations are traps for the unwary. There aren't enough places to put disclaimers about them, people constantly assume they're unique when they're not, and I've found far, far too many buggy date parsers that try to extract meaning from them. Replacing as many of them as possible with simple offset indications or some other mostly meaningless string is a service to future programmers as far as I'm concerned.
Just you wait to see what they come up with to generate the previous output! ;^>
Thankfully, we're well down the path of deprecating them in output. RFC 2822 marked all use of time zone abbreviations in Date headers obsolete in email (later adopted in Netnews as well by RFC 5536). ISO 8601 specifies using zone offsets, not abbreviations, and is increasingly widely adopted. strftime() is now far, far more common in new code that I see than ctime() and similar APIs. We're always going to be stuck with them in legacy files and code that has to parse old data, but we *can* push them slowly out of our software. I've been very pleased to see that dropping the more obscure and invented abbreviations has mostly broken test suites, not real code, at least from reports here. I haven't seen a legitimate reason to parse any time zone abbreviations other than the US ones (which were hard-coded in RFC 822) in quite some time, other than in a few archival applications handling very old files and formats. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
On 06/12/17 07:13, Russ Allbery wrote:
Just you wait to see what they come up with to generate the previous output! ;^>
Thankfully, we're well down the path of deprecating them in output. RFC 2822 marked all use of time zone abbreviations in Date headers obsolete in email (later adopted in Netnews as well by RFC 5536). ISO 8601 specifies using zone offsets, not abbreviations, and is increasingly widely adopted. strftime() is now far, far more common in new code that I see than ctime() and similar APIs. We're always going to be stuck with them in legacy files and code that has to parse old data, but we *can* push them slowly out of our software.
Current discussions on better support for timezones tend to fall at the first hurdle by complaining that some database values do not support it properly and EXPECT inclusion of the OFFSET in some way as the fix! So much more work needs to be done to promote the differences between simple offsets - however displayed - and the real identification of a clients timezone. I'll say yet again, the crude provision of an offset in the browser header as an abbreviation or even a simple number and trying to infer from that the relevant timezone is the main legacy problem. timezone_id is such a critical part of this process that the fact tzdist does not nail down even tzdb as a clean standard source is not taking things in the right direction, but using long strings as an id is equally troublesome when their content is only really valid in a small number of countries of the world? This is what makes abbreviations something internationalization tends to mistakenly rely on? This is where the geonames approach of defining a numeric id for every name in the world works so much better as systems can pick out their preferred language to display the result. My own method of normalizing historic timestamps is to only store UTC times, so I don't want the database to magically convert some arbitrary offset! The location of the event is much more important that 'somewhere in Europe' and in a large number of cases you need no more than the location with a UTC time ... if only we have a TZ database we could rely on for the information at the DATE of the event ;) -- 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 Mon, 4 Dec 2017 19:21:04 -0500, Michael Douglass <mikeadouglass@gmail.com> said:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
Everybody is free to do that now. The truth is that the names of tz regions have effectively formed a public interface that users have relied upon for more than two decades. (And no, telling people "just use some GUI picker" does not help the network administrator who needs to know what zone name to write in dhcpd.conf files on three continents.) -GAWollman
On Dec 5, 2017, at 11:31 AM, Garrett Wollman <wollman@csail.mit.edu> wrote:
<<On Mon, 4 Dec 2017 19:21:04 -0500, Michael Douglass <mikeadouglass@gmail.com> said:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish.
Everybody is free to do that now.
The truth is that the names of tz regions have effectively formed a public interface that users have relied upon for more than two decades. (And no, telling people "just use some GUI picker" does not help the network administrator who needs to know what zone name to write in dhcpd.conf files on three continents.)
How about "use a command-line picker", e.g. $ tzid "Dusseldorf" Europe/Berlin $ tzid "San Francisco" America/Los_Angeles $ tzid "San Francisco, Córdoba" America/Argentina/Cordoba $ tzid "San Francisco, Cordoba" America/Argentina/Cordoba $ tzid "Beijing" Asia/Shanghai Such a command would actually be better than some of the GUI pickers I've seen, as it actually handles cities other than the one that happened to be chosen for the tzid of the region in which it resides. It could presumably share the databases it uses with GUI pickers in the same OS, if any.
On 2017-12-05 13:04, Guy Harris wrote:
On Dec 5, 2017, at 11:31 AM, Garrett Wollman <wollman@csail.mit.edu> wrote:
<<On Mon, 4 Dec 2017 19:21:04 -0500, Michael Douglass <mikeadouglass@gmail.com> said:
Then we can stop having these long arguments about why one name or another isn't in the tz data. Everybody is free to generate their own list if they so wish. Everybody is free to do that now. The truth is that the names of tz regions have effectively formed a public interface that users have relied upon for more than two decades. (And no, telling people "just use some GUI picker" does not help the network administrator who needs to know what zone name to write in dhcpd.conf files on three continents.) How about "use a command-line picker", e.g. $ tzid "Dusseldorf" Europe/Berlin $ tzid "San Francisco" America/Los_Angeles $ tzid "San Francisco, Córdoba" America/Argentina/Cordoba $ tzid "San Francisco, Cordoba" America/Argentina/Cordoba $ tzid "Beijing" Asia/Shanghai Such a command would actually be better than some of the GUI pickers I've seen, as it actually handles cities other than the one that happened to be chosen for the tzid of the region in which it resides. It could presumably share the databases it uses with GUI pickers in the same OS, if any.
Not hard to put together a script using a "what is my external IP address" script that accesses an external web server to return your system's public address, geoiplookup, and tzselect -n 1 -c latlong, although YMMV. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Dec 5, 2017, at 12:35 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
Not hard to put together a script using a "what is my external IP address" script that accesses an external web server to return your system's public address, geoiplookup, and tzselect -n 1 -c latlong, although YMMV.
That's a start, but if it determines you're in San Simon, Arizona: https://en.wikipedia.org/wiki/San_Simon,_Arizona it gets it wrong: $ ksh ./tzselect.ksh -n 1 -c +3216-10913 Please identify a location so that time zone rules can be set correctly. Please select one of the following time zone regions, listed roughly in increasing order of distance from +3216-10913. 1) Mexico - Mountain Standard Time - Sonora #? So, for doing a script to do the equivalent of what macOS and iOS do, you'd want more like "get your external IP address, geolocate it, and hand it to a program with a set of shapefiles for tzdb regions". See, for example https://github.com/evansiroky/timezone-boundary-builder (to which http://efele.net/maps/tz/world/ now refers people).
On 2017-12-05 14:29, Guy Harris wrote: > On Dec 5, 2017, at 12:35 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote: >> Not hard to put together a script using a "what is my external IP address" >> script that accesses an external web server to return your system's public >> address, geoiplookup, and tzselect -n 1 -c latlong, although YMMV. > That's a start, but if it determines you're in San Simon, Arizona: > https://en.wikipedia.org/wiki/San_Simon,_Arizona > it gets it wrong: > $ ksh ./tzselect.ksh -n 1 -c +3216-10913 > Please identify a location so that time zone rules can be set correctly. > Please select one of the following time zone regions, > listed roughly in increasing order of distance from +3216-10913. > 1) Mexico - Mountain Standard Time - Sonora > #? > So, for doing a script to do the equivalent of what macOS and iOS do, you'd > want more like "get your external IP address, geolocate it, and hand it to a > program with a set of shapefiles for tzdb regions". See, for example > https://github.com/evansiroky/timezone-boundary-builder > (to which > http://efele.net/maps/tz/world/ > now refers people). More likely query the underlying geodatabase for the time zone region, often indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y] surrounding the possibly non-convex hull, then resolve muiltiple hits by checking the interior convex polygons contain the coordinate, or equivalent tests. There may still be a problem if the coordinate lies *on* a boundary line, which could be resolved by finding the (largest) nearest populated settlement in the geodatabase, and using those coordinates for the query. The query could also be restated as finding the time zone of the (largest) nearest populated settlement to the coordinates, -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Dec 6, 2017, at 8:50 AM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2017-12-05 14:29, Guy Harris wrote:
So, for doing a script to do the equivalent of what macOS and iOS do, you'd want more like "get your external IP address, geolocate it, and hand it to a program with a set of shapefiles for tzdb regions". See, for example https://github.com/evansiroky/timezone-boundary-builder (to which http://efele.net/maps/tz/world/ now refers people).
More likely query the underlying geodatabase for the time zone region, often indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y] surrounding the possibly non-convex hull, then resolve muiltiple hits by checking the interior convex polygons contain the coordinate, or equivalent tests.
That's what I meant by "hand it to a program with a set of shapefiles for tzdb regions".
On 2017-12-06 10:58, Guy Harris wrote:
On Dec 6, 2017, at 8:50 AM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2017-12-05 14:29, Guy Harris wrote:
So, for doing a script to do the equivalent of what macOS and iOS do, you'd want more like "get your external IP address, geolocate it, and hand it to a program with a set of shapefiles for tzdb regions". See, for example https://github.com/evansiroky/timezone-boundary-builder (to which http://efele.net/maps/tz/world/ now refers people). More likely query the underlying geodatabase for the time zone region, often indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y] surrounding the possibly non-convex hull, then resolve muiltiple hits by checking the interior convex polygons contain the coordinate, or equivalent tests. That's what I meant by "hand it to a program with a set of shapefiles for tzdb regions".
Sorry, to me a shapefile is an external data format used for interchange between GIS GUI products, distinct from the geodata used for its generation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
See https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01 On 12/6/17 13:09, Brian Inglis wrote:
On 2017-12-06 10:58, Guy Harris wrote:
On Dec 6, 2017, at 8:50 AM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2017-12-05 14:29, Guy Harris wrote:
So, for doing a script to do the equivalent of what macOS and iOS do, you'd want more like "get your external IP address, geolocate it, and hand it to a program with a set of shapefiles for tzdb regions". See, for example https://github.com/evansiroky/timezone-boundary-builder (to which http://efele.net/maps/tz/world/ now refers people). More likely query the underlying geodatabase for the time zone region, often indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y] surrounding the possibly non-convex hull, then resolve muiltiple hits by checking the interior convex polygons contain the coordinate, or equivalent tests. That's what I meant by "hand it to a program with a set of shapefiles for tzdb regions". Sorry, to me a shapefile is an external data format used for interchange between GIS GUI products, distinct from the geodata used for its generation.
On 12/06/2017 12:58 PM, Guy Harris wrote:
On Dec 6, 2017, at 8:50 AM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2017-12-05 14:29, Guy Harris wrote:
So, for doing a script to do the equivalent of what macOS and iOS do, you'd want more like "get your external IP address, geolocate it, and hand it to a program with a set of shapefiles for tzdb regions". See, for example https://github.com/evansiroky/timezone-boundary-builder (to which http://efele.net/maps/tz/world/ now refers people). More likely query the underlying geodatabase for the time zone region, often indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y] surrounding the possibly non-convex hull, then resolve muiltiple hits by checking the interior convex polygons contain the coordinate, or equivalent tests. That's what I meant by "hand it to a program with a set of shapefiles for tzdb regions".
Like so (a request against my local TZdist server with the geolocate extension and using the Siroky boundaries): GET /tzdist/zones?location=geo:32.16,-109.13,0 HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive HTTP/1.1 200 OK Date: Wed, 06 Dec 2017 18:06:10 GMT Cache-Control: must-revalidate, max-age=86400 Expires: Thu, 07 Dec 2017 18:06:10 GMT Vary: Accept-Encoding Accept-Ranges: bytes ETag: "890939292-1466089793" Last-Modified: Thu, 16 Jun 2016 15:09:53 GMT Content-Type: application/json; charset=utf-8 Content-MD5: f9xV70dO60dwRS+ukiKkPQ== Content-Length: 311 { "synctoken": "890939292-1466089793", "timezones": [ { "tzid": "America/Phoenix", "etag": "3297940-1466089793", "last-modified": "2016-06-16T15:09:53Z", "publisher": "IANA Time Zone Database", "version": "2016e", "aliases": [ "US/Arizona" ] } ] } -- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd
On 2017-12-05 00:18:10 (+0100), Michael Douglass wrote:
On 12/4/17 17:13, Clive D.W. Feather wrote:
Brian Inglis said:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. [...] Feel free to write a script to mv each path to its lat/long [...] What's wrong with just labelling the present zones with randomly allocated letter-digit-letter codes? That gives us 6760 codes that don't look like city names or commonly-used abbreviations. We can then reserve letter-letter-digit for future expansion and digit-letter-letter for private use.
As soon as people know it's lat/long, they'll try to map it to cities and the same arguments will start again.
Exactly - that's why I said opaque
What problem are we trying to solve here? Every couple of weeks someone asks on tz@ why their timezone is called City X instead of City Y or why City Z is not in the tzdb. Every now and again that turns into a lengthy discussion on politics. That problem is easily solved with a polite, terse reply pointing at the theory. Whether we like it or not, there is necessarily a mapping (however opaque) between a time zone name and a geographical region. We can give it any name we like but if we want to be able to keep the data accurate, we need to be able to map it back to the actual geographical region. While the list of names in tzdb isn't great, it's better to have one list of seemingly arbitrary cities and one mailing list where the (let's be honest: not all that many) questions about them go. Externalising this problem will only make maintaining the tzdb more difficult and needlessly confuse people. I think I like the problem we have more than the new problems being proposed in this thread. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On Dec 4, 2017, at 10:22 PM, Philip Paeps <philip@trouble.is> wrote:
What problem are we trying to solve here?
Every couple of weeks someone asks on tz@ why their timezone is called City X instead of City Y or why City Z is not in the tzdb. Every now and again that turns into a lengthy discussion on politics. That problem is easily solved with a polite, terse reply pointing at the theory.
How about the problem of "the questions keep being asked", a solution to which would have to prevent the question from being asked, or, at least, reduce the frequency with which it's asked and, if that's not possible, at *least* arrange that people don't argue back once we've pointed them at the theory.
While the list of names in tzdb isn't great, it's better to have one list of seemingly arbitrary cities and one mailing list where the (let's be honest: not all that many) questions about them go.
Better to have that than, say, one list of either 1) *definitely* arbitrary 4-character identifiers (from Clive Feather's proposal) or 2) longitude/latitude values for a location that happens to be within the city, plus one mailing list where questions about them go?
Externalising this problem will only make maintaining the tzdb more difficult and needlessly confuse people.
How does using something other than city names constitute "externalizing this problem"?
On Dec 5, 2017, at 3:33 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Dec 4, 2017, at 10:22 PM, Philip Paeps <philip@trouble.is> wrote:
What problem are we trying to solve here?
Every couple of weeks someone asks on tz@ why their timezone is called City X instead of City Y or why City Z is not in the tzdb. Every now and again that turns into a lengthy discussion on politics. That problem is easily solved with a polite, terse reply pointing at the theory.
How about the problem of "the questions keep being asked", a solution to which would have to prevent the question from being asked, or, at least, reduce the frequency with which it's asked and, if that's not possible, at *least* arrange that people don't argue back once we've pointed them at the theory.
I don't think that "people keep asking a question that's already adequately answered in the theory file which they didn't read" is a reason to change things. Some questions are not worth answering. Opaque names may be no help at all. Political trolls still will find a way to troll. And substituting, say, lat/long for a name doesn't help because that's just a nickname for a particular place, and people will still ask why THAT place and not the place they prefer. paul
On Tue, 5 Dec 2017, Paul.Koning@dell.com wrote:
Opaque names may be no help at all. Political trolls still will find a way to troll. And substituting, say, lat/long for a name doesn't help because that's just a nickname for a particular place, and people will still ask why THAT place and not the place they prefer.
It is IMO a lot harder to discuss a rule for e.g. "876UDAS" compared to Europe/London. cheers, Derick
On 2017-12-04 15:13, Clive D.W. Feather wrote:
Brian Inglis said:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. Feel free to write a script to mv each path to its lat/long (and create a link to its previous name(s) for compatibility) as that is the only other reasonably stable property of the tz db usable as a name and a l14n reference: otherwise people will assume the id will always be around and mean something, as with zone names, country codes, tz abbrs, etc. What's wrong with just labelling the present zones with randomly allocated letter-digit-letter codes? That gives us 6760 codes that don't look like city names or commonly-used abbreviations. We can then reserve letter-letter-digit for future expansion and digit-letter-letter for private use.
Arbitrary codes are just another level of indirection, and should only be used for internal machine representations to which is attached some arbitrary descriptive content with no semantic value, which may be arbitrarily changed to some other descriptive value by a user, not anything to be exposed to, used, or comprehended by a human. If they are fixed values, as they must be to support l14n, users and programmers will presume the semantics of whatever is represented by the id, as they have with tz abbreviation labels, so you get similar issues.
As soon as people know it's lat/long, they'll try to map it to cities and the same arguments will start again.
The issues in this group seem to focus on countries, cities, and names. Using lat/long avoids those issues, and is an existing semantic property of a zone, about which we rarely have questions, and even fewer corrections. Theory could instead expound upon selection of observatories, universities, clock towers, settlements, and municipalities chosen to represent a zone, and their coordinates. They can map it to cities or whatever they wish to support in their locales, but that will be their or CLDR's problem, not an issue for this list, as /even/ David Patte agrees ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Michael Douglass <mikeadouglass@gmail.com> writes:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it.
This strikes me as a remarkably bad idea. Reality is that the existing tzdb zone names are a de facto part of the universe now. Whether you think that they ought to be used in UIs or not, *they are so used*, and you aren't going to get anywhere by telling people not to. I can positively guarantee that if those names are replaced by meaningless IDs, the very first thing that the Postgres project will do is build a mapping table between those IDs and the old names, and continue to expose the old names in our UI. I confidently predict that a majority of other consumers of the tz database will do likewise. regards, tom lane
On 12/4/17 21:04, Tom Lane wrote:
Michael Douglass <mikeadouglass@gmail.com> writes:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it. This strikes me as a remarkably bad idea. Reality is that the existing tzdb zone names are a de facto part of the universe now. Whether you think that they ought to be used in UIs or not, *they are so used*, and you aren't going to get anywhere by telling people not to.
I can positively guarantee that if those names are replaced by meaningless IDs, the very first thing that the Postgres project will do is build a mapping table between those IDs and the old names, and continue to expose the old names in our UI. I confidently predict that a majority of other consumers of the tz database will do likewise. There's nothing to stop people using those names if they so wish - it's just a simple mapping. I suggested that such a mapping table should be provided. The point is to move the arguments over names out of this project. Also to stop misleading people into believing the current tz names and aliases have any official meaning.
There are a number of organizations which are much more appropriate for handling naming.
regards, tom lane
On Mon, 4 Dec 2017, Tom Lane wrote:
Michael Douglass <mikeadouglass@gmail.com> writes:
I'd suggest a first step would be to provide a unique - reasonably short - opaque id for each definition. That allows us to build out a localization framework around it.
This strikes me as a remarkably bad idea. Reality is that the existing tzdb zone names are a de facto part of the universe now. Whether you think that they ought to be used in UIs or not, *they are so used*, and you aren't going to get anywhere by telling people not to.
I can positively guarantee that if those names are replaced by meaningless IDs, the very first thing that the Postgres project will do is build a mapping table between those IDs and the old names, and continue to expose the old names in our UI. I confidently predict that a majority of other consumers of the tz database will do likewise.
Yes. I would instantly implement that for both PHP and MongoDB. cheers, Derick
On Tue, Dec 5, 2017 at 9:14 AM, Derick Rethans <tz@derickrethans.nl> wrote:
On Mon, 4 Dec 2017, Tom Lane wrote:
I can positively guarantee that if those names are replaced by meaningless IDs, the very first thing that the Postgres project will do is build a mapping table between those IDs and the old names, and continue to expose the old names in our UI. I confidently predict that a majority of other consumers of the tz database will do likewise.
Yes. I would instantly implement that for both PHP and MongoDB.
If this wasn't fixed upstream in PHP first, the Drupal project would have to do this to maintain its backwards compatibility policy, and would cause a fair amount of technical debt for that subsystem (I am one of the maintainers). It would also probably cause backwards compatibility work regardless. I suspect the Wordpress project would be in the same boat. And to answer some questions that have popped up in this thread(s), from the perspective of a tzdb consumer. For better or worse, we expose the raw list of names to let site administrators and users pick from. I am well aware that this isn't the ideal or intended situation, but fixing that portion of the codebase is a lower priority that other parts right now. Our issue queue is mostly English based, so that may skew things, but we only get a handful of "why isn't my city listed". I think most have been when names have moved to the backzone (eg, Montreal). I think our end users are used to the name list, as it is pervasive in PHP based projects and has been for years. Abbreviation changes. This doesn't come up as a problem with our end users (I don't recall seeing any issues in our queue). One of the removals (think it was the Chile one) caused an automated testing problem, but this was quickly resolved. --Matthew Donadio (matt@mxd120.com)
Thomas M Steenholdt <tmus@tmus.dk> writes:
Paul Eggert wrote:
As far as I can see, it's an invented abbreviation propagated from tzdata, and there isn't much independent support for it. I've been trying to omit these inventions, as tzdata should record timekeeping not invent it.
I have gathered a few sources that mention WGT/WGST, but I honestly have no clue if these are based of off tzdata (which could very well be the case) or something else.: ... In any case I can't help feeling, that with all this "knowledge" out there, removing the WGT/WGST timezone abbreviations from tzdata seems wrong. These are the TZ abbreviations that we work with on a daily basis up here (I'm in Nuuk, Greenland) and suddenly they are unknown in our favorite timezone data.
FWIW, I tend to share the suspicion that these zone abbreviations have become normalized simply because they've been in widely-recognized reference data (to wit, tzdb) for years. Very few non-experts will know that they had no standing otherwise. The Postgres project has so far refrained from removing them from what we recognize in timestamp input, because we fear the backlash if we do. Most of our timestamp output formats represent timezone offsets numerically, so that the issue doesn't arise so much on that side, and it happens that our list of abbreviations recognized for input is separate from the tzdb data proper. regards, tom lane
Thomas M Steenholdt wrote:
From what I've seen, PHP (on Ubuntu) had some hiccups and started mentioning Sao Paolo in my date/time outputs, because WGT/WGST was suddenly missing:
As I understand from <https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1734967>, PHP attempts to guess the tzdb Zone name (e.g., "Europe/Berlin") from the abbreviation and UT offset, which is the sort of thing that we have long explicitly warned should not be done because abbreviations are ambiguous. Although you may now have noticed the problem with Western Greenland and Sao Paolo, surely other users can run into similar problems with (say) Algeria and Berlin. (Algeria and Germany have the same standard UT offset but differing DST rules, and in that respect are like western Greenland vs. southern Brazil.) I'm afraid that the sources that you mention are derived from tzdata. Generally speaking, we're looking for general-interest English-language sources, such as newspapers, magazines, books and the like. A few tzdata-derived abbreviations have made it into popular usage, and we've kept them.
On Sun, 3 Dec 2017, Paul Eggert wrote:
Thomas M Steenholdt wrote:
From what I've seen, PHP (on Ubuntu) had some hiccups and started mentioning Sao Paolo in my date/time outputs, because WGT/WGST was suddenly missing:
As I understand from <https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1734967>, PHP attempts to guess the tzdb Zone name (e.g., "Europe/Berlin") from the abbreviation and UT offset, which is the sort of thing that we have long explicitly warned should not be done because abbreviations are ambiguous.
PHP does not guess tzdb names from abbreviations/UT offsets by default, it hasn't since 2011 (PHP 5.5): https://github.com/php/php-src/commit/37d1038958a6442de8f559a443f117c6ae1c2d... There are still functions to guess the timezone from abbreviation + offset, but that is a developers choice: http://php.net/manual/en/function.timezone-name-from-abbr.php I'll go add a warning to the docs defining it as "deprecated". Input routines (strtotime()) also still allow the use of abbreviations where they are defined in tzdata, in which case the are statically mapped to tzdb names: https://github.com/php/php-src/blob/master/ext/date/lib/fallbackmap.h — which has not changed to keep backwards compatibility (VET is still wrong in it, for example). cheers, Derick
On 2017-12-03 19:04, Thomas M Steenholdt wrote:
Paul Eggert wrote:
Thomas M Steenholdt wrote:
WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone.
As far as I can see, it's an invented abbreviation propagated from tzdata, and there isn't much independent support for it. I've been trying to omit these inventions, as tzdata should record timekeeping not invent it.
I totally agree. I just never thought this was something invented or unofficial - I've always used these.
I have gathered a few sources that mention WGT/WGST, but I honestly have no clue if these are based of off tzdata (which could very well be the case) or something else.: In any case I can't help feeling, that with all this "knowledge" out there, removing the WGT/WGST timezone abbreviations from tzdata seems wrong. These are the TZ abbreviations that we work with on a daily basis up here (I'm in Nuuk, Greenland) and suddenly they are unknown in our favorite timezone data.
Air Greenland office hours are specified as GMT-3; some hotel events are specified as UTC-02/03; most other times: air and sea schedules, opening hours, election times, are unspecified local; so not a lot of evidence for actual use of WGT/WGST in Greenland. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Sun, 3 Dec 2017, Thomas M Steenholdt wrote:
So I'm more inclined to try to somehow make these abbreviations official. I just need to know where to start.
Get your official government department in charge of Time and Time Zones to declare an official abbreviation (preferably with some sort of "mandate" for its use in other government documents/records), and publish it in some sort of official government record/log? +------------------+--------------------------+----------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +------------------+--------------------------+----------------------------+
On 2017-12-04 06:06, Paul Goyette wrote:
On Sun, 3 Dec 2017, Thomas M Steenholdt wrote:
So I'm more inclined to try to somehow make these abbreviations official. I just need to know where to start.
Get your official government department in charge of Time and Time Zones to declare an official abbreviation (preferably with some sort of "mandate" for its use in other government documents/records), and publish it in some sort of official government record/log?
I'll try to see what I can do about that. In the meantime, here's a link to a publication created by a government owned entity (Asiaq) and published on an official governmental website (govmin.gl), which uses WGT/WGST and EGT/EGST: https://www.govmin.gl/images/stories/minerals/events/Perth_2015/Forsberg_Asi... /Thomas
On Sun, 3 Dec 2017, Thomas M Steenholdt wrote:
Which things went belly up? Details might be helpful.
From what I've seen, PHP (on Ubuntu) had some hiccups and started mentioning Sao Paolo in my date/time outputs, because WGT/WGST was suddenly missing:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1734967
PHP follows tzdata, and there are some quite false assumptions made in the thread in that bug report.
A few of my own scripts that convert time between timezones started misbehaving as they expect WGT and WGST to be valid abbreviations. This is easy to fix, but there could be (and probably is) other places where this could cause problems.
In applications, timezone abbreviations should really only be used for output, and not for recording which timezone a specific event happened in. Relying on the UTC offsets they are linked too is a flawed approach. I have never been keen on the removal of these invented timezone abbreviations, but it *does* highlight that using them for conversions is very fragile. You should endavour to remove the reliance on these abbreviations. cheers, Derick (The PHP Date/Time maintainer) -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug
On Sun, 3 Dec 2017, Paul Eggert wrote:
At any rate, now that I've pretty much finished the job we should document the alphabetic abbreviations used. To give that a go I installed the attached patch into the development version on GitHub.
I think you're missing "IST" for "Irish Standard Time", which as far as I know is Ireland's legal definition of time (and equivalent with BST), with GMT being their "odd one out": https://en.wikipedia.org/wiki/Time_in_Ireland / http://www.irishstatutebook.ie/eli/1968/act/23/enacted/en/print cheers, Derick
On 12/04/2017 02:00 AM, Derick Rethans wrote:
I think you're missing "IST" for "Irish Standard Time"
Thanks, good catch (I assume you meant "Irish Summer Time"). I installed the first attached patch to fix that. IST is interesting because in summer 1916 it meant +00:34:38.9 as opposed to the modern +01. Come to think of it, it's worth documenting the Dublin/Dunsink issue a bit more, including the question whether DMT was -00:25:21.1 or -00:25:22. It's possible that we're missing an 0.9-second transition for Dublin/Dunsink circa 1896, which presumably we'd model as a 1-second-transition! I'll leave that just as a comment for now. I installed the second attached patch, plus the third to fix a typo.
On Mon 2017-12-04T10:37:35-0800 Paul Eggert hath writ:
Come to think of it, it's worth documenting the Dublin/Dunsink issue a bit more, including the question whether DMT was -00:25:21.1 or -00:25:22. It's possible that we're missing an 0.9-second transition for Dublin/Dunsink circa 1896, which presumably we'd model as a 1-second-transition! I'll leave that just as a comment for now. I installed the second attached patch, plus the third to fix a typo.
Thumbing through early issues of Bulletin Horaire, the journal of the International Time Bureau (BIH), quickly shows that actual times provided by observatories as the legal times for various jurisdictions commonly had varying offsets of many tenths of seconds from the intended times indicated by official documents. There are not many contenders for a more boring publication than the nearly 100 years of tabulations of how wrong various official clocks have been, but nestled in the introductions to each issue there are other passing references about when various observatories changed their rules, algorithms, and/or conventional longitudes and thus had a leap in the time they provided to their region. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Mon, 4 Dec 2017, Paul Eggert wrote:
On 12/04/2017 02:00 AM, Derick Rethans wrote:
I think you're missing "IST" for "Irish Standard Time"
Thanks, good catch (I assume you meant "Irish Summer Time").
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT". cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug
On 12/05/2017 02:16 AM, Derick Rethans wrote:
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT". Thanks for pointing this out; I was unaware that Ireland observes negative daylight-saving time in winter, instead of positive daylight-saving time in summer. This arguably is clearer than the common practice in North America and Europe, where "standard time" is observed only in a relatively small fraction of the year. I installed the attached proposed patch to fix the commentary along the lines that you suggested, and to change tm_isdst as well. UT offsets and abbreviations are unaffected by this change.
On 2017-12-08 06:38, Paul Eggert wrote:
+# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT
I'm a bit surprised that it seems to be so easy to extend the input format for zic (negative SAVE values) -- in other cases, a lot more lead time has been allowed for (eg, %z in FORMATs). Be that as it may, such extensions must be documented. For instance, the description (from zic(8)) SAVE Gives the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the AT field (although, of course, the w and s suffixes are not used). needs to be changed -- unless we want to allow for negative AT values as well. Do we? Michael Deckers. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Michael Deckers via tz wrote:
I'm a bit surprised that it seems to be so easy to extend the input format for zic (negative SAVE values)
That's not a change to the format that zic accepts. Note the lack of zic.c patch.
unless we want to allow for negative AT values as well.
zic already does allow negative AT times. There are no examples in the database, though. zic.8 ought to be patched to make explicit that AT and SAVE have no small range limits. -zefram
On 2017-12-08 08:26, Zefram wrote:
That's not a change to the format that zic accepts.
Well, I did not mean the input accepted by any particular implementation of zic but the public interface described in zic(8), the definition of the format of tzdb data. If some zic implementation accepts complex numbers as SAVE values that does not mean we can use it in tzdb data.
zic already does allow negative AT times.
Interesting. Allowing negative AT values would provide a "convenient notation" to avoid the Chatham Rules, as in Rule NZ 2008 max - Apr Sun>=1 -10:00u 0 S
zic.8 ought to be patched to make explicit that AT and SAVE have no small range limits.
Yes, and it may also be necessary to state the meaning of such extensions; for instance, the suffixes u, g, z currently are allowed for SAVE values but they cannot really be used because it is not clear what they are supposed to mean in this context. Michael Deckers.
On 12/08/2017 12:12 PM, Michael Deckers via tz wrote:
Allowing negative AT values would provide a "convenient notation" to avoid the Chatham Rules, as in
Rule NZ 2008 max - Apr Sun>=1 -10:00u 0 S
Good point. I hadn't thought of that. We should make that change in a year or two, after the zic.8 documentation change has had time to percolate.
zic.8 ought to be patched to make explicit that AT and SAVE have no small range limits.
Yes, and it may also be necessary to state the meaning of such extensions; for instance, the suffixes u, g, z currently are allowed for SAVE values but they cannot really be used because it is not clear what they are supposed to mean in this context.
Sorry, I don't see a problem here. The u suffix means "treat the date and time as UTC". If the time is -02:00, that means 22:00 the previous day UTC. I installed the attached patch to zic.8 to try to document the longstanding zic interpretation better.
On 8 December 2017 at 16:01, Paul Eggert <eggert@cs.ucla.edu> wrote:
Yes, and it may also be necessary to state the meaning
of such extensions; for instance, the suffixes u, g, z currently are allowed for SAVE values but they cannot really be used because it is not clear what they are supposed to mean in this context.
Sorry, I don't see a problem here. The u suffix means "treat the date and time as UTC". If the time is -02:00, that means 22:00 the previous day UTC.
If I'm reading correctly, I think the point is that these suffixes, while meaningful in the AT field, are currently meaningless in the SAVE field even though they're technically permitted there? -- Tim Parenti
On 12/08/2017 01:05 PM, Tim Parenti wrote:
If I'm reading correctly, I think the point is that these suffixes, while meaningful in the AT field, are currently meaningless in the SAVE field even though they're technically permitted there?
Ah, thanks, I misinterpreted his email. I think my proposed patch addresses the problem by changing zic.8 to say that SAVE fields should not have any suffixes.
I am worried that a significant number of implementations may keel over if handed negative offsets. I'm not quite sure what the motivation for such a potentially destabilizing change its. If the only purpose is to call one of the two times "Irish Standard Time" and the other "GMT", then that seems a simple matter of changing the naming, not other changes to the data. Mark Mark <https://twitter.com/mark_e_davis> On Fri, Dec 8, 2017 at 10:07 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/08/2017 01:05 PM, Tim Parenti wrote:
If I'm reading correctly, I think the point is that these suffixes, while meaningful in the AT field, are currently meaningless in the SAVE field even though they're technically permitted there?
Ah, thanks, I misinterpreted his email. I think my proposed patch addresses the problem by changing zic.8 to say that SAVE fields should not have any suffixes.
On 2017-12-09 14:00, Mark Davis ☕️ wrote:
I'm not quite sure what the motivation for such a potentially destabilizing change its. If the only purpose is to call one of the two times "Irish Standard Time" and the other "GMT", then that seems a simple matter of changing the naming, not other changes to the data.
I think you raise an important point here. The proposal at hand has as its (only observable) effect that the dst bit is set to 1 during Irish winter time (UTC), and 0 during Irish standard time (UTC + 01 h). Taken together with all the other cases (where the dst bit value 1 indicates daylight saving or summer time as opposed to standard time) this implies that the semantics of the dst bit would be: The dst bit is set to 1 while the time scale differs from what is considered to be standard time for the time zone, such as when daylight saving time or summer time is used. That is a perfectLy possible semantics -- but it just is not the semantics currently described with the tzdb releases. In fact, the current description conforms with the tm_isdst bit defined in the international standards for the C language and for POSIX from 1989 until today for the tm_isdst member of struct tm: The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." (Note the spurious s after saving!) For instance, in newctime we read: Tm_isdst is non-zero if summer time is in effect. Thus, the current definition of the dst bit of a time zone time scale appears to be: The dst bit is set to 1 while the time scale represents daylight saving time or summer time. Of course one can change the current definition -- but in this case we should make an explicit decision to do so, after considering all the effects of such a change, and we also should make sure that the change is consistently documented in all the interfaces specified by tzdb. This is a design question, not just the question of whether a particular patch is OK. Michael Deckers.
On 12/09/2017 06:00 AM, Mark Davis ☕️ wrote:
I am worried that a significant number of implementations may keel over if handed negative offsets.
So far we've found one specific trivial formatting glitch <https://mm.icann.org/pipermail/tz/2017-December/025696.html>, and one library <https://mm.icann.org/pipermail/tz/2017-December/025694.html> with a debugging assertion about DST offsets that was incorrect. If these examples are typical, then there is little to worry about; if more-significant problems show up, then the tzdata change may need to be reverted. There is a tension here between trying to support daylight-saving time practice, and trying to keep our code and machines running. Although we want both objectives, they sometimes compete. Here the gain is small (supporting IST as it was intended). If the cost is trivial (a few formatting glitches or debug runs fail until software is corrected) then the gain is worth the cost; if the cost is large (some user programs crash in typical operation) then it's not. So far we've seen only trivial costs. PS. Howard, that debugging assertion change <https://github.com/HowardHinnant/date/commit/1eeb4cd6522da8c05ccadf3868a076b...> still looks dicey. It still forbids 3-hour DST, for example, even though POSIX TZ strings and the tzfile format both require support for 3-hour DST. POSIX requires support for UT offsets ranging from -24:00 to 24:59:59, so in theory the difference between DST and STD could be in the range -48:59:59 .. 48:59:59. tzdata supports offsets that are way wider, for what it's worth.
On 12/09/2017 11:11 AM, Paul Eggert wrote:
POSIX requires support for UT offsets ranging from -24:00 to 24:59:59
Whoops, wrong value. POSIX actually allows UT offsets from -24:59:59 to 24:59:59, so POSIX daylight-saving and standard time can differ by almost 50 hours in either direction.
On Dec 9, 2017, at 2:11 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
PS. Howard, that debugging assertion change <https://github.com/HowardHinnant/date/commit/1eeb4cd6522da8c05ccadf3868a076b...> still looks dicey. It still forbids 3-hour DST, for example, even though POSIX TZ strings and the tzfile format both require support for 3-hour DST. POSIX requires support for UT offsets ranging from -24:00 to 24:59:59, so in theory the difference between DST and STD could be in the range -48:59:59 .. 48:59:59. tzdata supports offsets that are way wider, for what it's worth.
Agreed, there is some tricky logic in my local->utc lookup in detecting ambiguous and non-existent mappings. The logic could be made simpler, but at a performance cost. The job of that assert is to warn me if I need to double-check that logic. It did exactly what I needed it to this time: I widened the window on save, and reran the unit tests and confirmed that the only thing that changed was exactly what should have changed. If save is allowed to vary from -inf to inf, I know my code will break. I have different logic for handling posix-style timezones: https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h#L262-L3... which will not break with an arbitrary save. However that code makes assumptions that are correct for posix, and incorrect for the IANA tzdb. For one, that the offset for in the prior and next transitions is trivially known without a lookup. Maybe some day I will rewrite the logic for the IANA parser that I have more confidence in for a wider range of save. But for now that assert is my quality assurance. Howard PS: I have no position on the IST/save issue. Yes, I think reports will come in. I don’t know how many or how serious they will be. I fixed my lib and am ready to go for this patch.
On 2017-12-09 12:11, Paul Eggert wrote:
On 12/09/2017 06:00 AM, Mark Davis ☕️ wrote:
I am worried that a significant number of implementations may keel over if handed negative offsets. There is a tension here between trying to support daylight-saving time practice, and trying to keep our code and machines running. Although we want both objectives, they sometimes compete. Here the gain is small (supporting IST as it was intended). If the cost is trivial (a few formatting glitches or debug runs fail until software is corrected) then the gain is worth the cost; if the cost is large (some user programs crash in typical operation) then it's not. So far we've seen only trivial costs.
Does it matter what is labelled "Standard" by politicians making points? The expectation is that if there is any deviation from standard time, it is an advance during summer in that hemisphere, not a regression during winter. We could just leave the zone as standard +0 daylight +1, as that data reflects the actual situation and practice, and our concern has never been about labels. Otherwise this is an atypical new case in the data provided by the project. It should be flagged for downstream as a possibly breaking change for tests, and for code on platforms not using the reference implementation. As with removal of historical abbreviations, there is a risk of possible downstream impacts post-release, delaying propagation of required data changes. It would be useful if major downstream distros, vendors, and platforms could test against the experimental repo and provide feedback prior to any release. If testing against the experimental repo was incorporated into inter-release CI processes, it could provide valuable pre-release feedback, and avoid "surprise" regressions on release. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Dec 9, 2017, at 4:41 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
Otherwise this is an atypical new case in the data provided by the project. It should be flagged for downstream as a possibly breaking change for tests, and for code on platforms not using the reference implementation.
As with removal of historical abbreviations, there is a risk of possible downstream impacts post-release, delaying propagation of required data changes.
It would be useful if major downstream distros, vendors, and platforms could test against the experimental repo and provide feedback prior to any release. If testing against the experimental repo was incorporated into inter-release CI processes, it could provide valuable pre-release feedback, and avoid "surprise" regressions on release.
Any major downstream distro, vendor, or platform that is relying on this code/database and is *not* monitoring this mailing list does not have the qualifications to deliver top quality software. I’m a very minor vendor, and for an unpaid gig at that. And even I take the time to monitor this mailing list for breaking changes. The github repo, and the patches that Paul emails here are wonderful. That imho is more than sufficient notice and availability for pre-release testing. If I can do it on hobby budget & time, any major vendor/distro that is not doing such monitoring and testing is just incompetent. All that being said, careful weighing of the benefit/cost ratio by this group for every change is much appreciated. In the future this database will continue to grow as an international de facto standard for global time keeping. There is a proposal before the C++ standards committee right now to create an API based not on the code this group supplies, but on the database, and most specifically, the time zone identifiers in the database: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0355r4.html Not to worry, it is the intent of this proposal that vendors of the C++ compiler and library supply the database, and not https://www.iana.org/time-zones. Indeed, many platforms already do so in the form of the zic-compiled files (though the zic-compiled form is not required). Howard
On 12/09/2017 01:41 PM, Brian Inglis wrote:
Does it matter what is labelled "Standard" by politicians making points?
A bit, but what's more important is common practice among English-speakers. For what it's worth, a Google search from UCLA today found 20 hits for the search '"Irish Standard Time IST" site:ie', and 9 hits for '"Irish Summer Time IST" site:ie'. The former hits include the Limerick Leader, the Dublin City Council, the Commission for Energy Regulation, and Gaelectric; the latter include Air Accident Investigation Unit Ireland and the School of Physics,Trinity College Dublin. If I change the spelling of the query to find more matches, '"Irish Standard Time" IST site:ie' finds 32 hits, and '"Irish Summer Time IST" site:ie' finds 22 hits. Another example that includes sources outside the Ireland top-level domain: '"Irish Standard Time" IST' has about 25,800 hits, and '"Irish Summer Time" IST' has about 11,100 hits. So these admittedly-crude Google searches suggest that "Irish Standard Time" is the more-common interpretation of IST in Ireland.
On 10/12/17 07:21, Paul Eggert wrote:
On 12/09/2017 01:41 PM, Brian Inglis wrote:
Does it matter what is labelled "Standard" by politicians making points?
A bit, but what's more important is common practice among English-speakers.
For what it's worth, a Google search from UCLA today found 20 hits for the search '"Irish Standard Time IST" site:ie', and 9 hits for '"Irish Summer Time IST" site:ie'. The former hits include the Limerick Leader, the Dublin City Council, the Commission for Energy Regulation, and Gaelectric; the latter include Air Accident Investigation Unit Ireland and the School of Physics,Trinity College Dublin. If I change the spelling of the query to find more matches, '"Irish Standard Time" IST site:ie' finds 32 hits, and '"Irish Summer Time IST" site:ie' finds 22 hits. Another example that includes sources outside the Ireland top-level domain: '"Irish Standard Time" IST' has about 25,800 hits, and '"Irish Summer Time" IST' has about 11,100 hits. So these admittedly-crude Google searches suggest that "Irish Standard Time" is the more-common interpretation of IST in Ireland.
Since the tzdb is 'non-political', common interpretation can be taken as the rule, and since tzdb is only deemed to be accurate for dates since 1970, information such as the Irish Summer Time Act of 1925 are also out of scope. As Stephen says, EU law currently applies to the whole of the EU area, and defines daylight saving ( question perhaps is when did that apply to Ireland? ) so should there be any timezones other than a single European time in the tzdb database? Pre-1970 history still needs a home somewhere and is still as relevant today as we refer back to pre-1970 times regularly and there IS a growing archive of legal statutes that document the political decisions on who that history changed. -- 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
Lester Caine wrote:
so should there be any timezones other than a single European time in the tzdb database?
Yes, of course. The EU rules cover multiple time zones and the tzdata format needs different Zones for each. But it's more than that: the EU didn't standardize daylight-saving transition rules until 1977. So time zone histories that differ in the 1970-1976 period require different Zones regardless of EU rules after 1977.
Paul Eggert wrote:
the EU didn't standardize daylight-saving transition rules until 1977.
I should have written "the European Communities", since the EU didn't exist in 1977. I see that our commentary is a bit confused about this issue. I attempted to fix the problems I found by installing the attached changes to the commentary.
On 10/12/17 23:45, Paul Eggert wrote:
I should have written "the European Communities", since the EU didn't exist in 1977. I see that our commentary is a bit confused about this issue. I attempted to fix the problems I found by installing the attached changes to the commentary.
The the membership of the Community has evolved over many years so some countries have only come in line in recent years and no doubt there may be further additions. -- 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
Paul Eggert said:
Yes, of course. The EU rules cover multiple time zones and the tzdata format needs different Zones for each. But it's more than that: the EU didn't standardize daylight-saving transition rules until 1977.
1980, coming into effect in 1981. -- 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
Lester Caine said:
Since the tzdb is 'non-political', common interpretation can be taken as the rule, and since tzdb is only deemed to be accurate for dates since 1970, information such as the Irish Summer Time Act of 1925 are also out of scope.
I completely disagree. If the Irish Summer Time Act of 1925 was still in force in 1970, then it applies to dates within the scope of tzdb. Are you saying that the UK isn't really on GMT because GMT was invented before 1970? Or that the entry for Europe/London shouldn't have anything for the period before 1978 because, until then, time was defined by an 1880 Act (43 & 44 Vict. c.9)? In any case, the current Irish legislation is the Standard Time (Amendment) Act 1971.
As Stephen says, EU law currently applies to the whole of the EU area, and defines daylight saving ( question perhaps is when did that apply to Ireland? )
Ireland joined the EU in 1973, the same as the UK and Denmark. But the first Summer Time Directive (80/737/EEC) was issued in 1980.
so should there be any timezones other than a single European time in the tzdb database?
EU law does not define a European time zone. It defines summer time switching dates and the amount by which time changes. Mainland EU uses three time zones, but other parts of the EU use others. -- 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 2017-12-12 12:50, Clive D.W. Feather wrote:
In any case, the current Irish legislation is the Standard Time (Amendment) Act 1971.
Yes, at [http://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print.html]. It introduces "winter time", but it does not repeal the "Standard Time Act, 1968" at [http://www.irishstatutebook.ie/eli/1968/act/23/enacted/en/print.html]. The latter defines "standard time" as GMT + 01 h, but it does not make summer time illegal. In fact, it states that "summer time" is an allowed designation for GMT + 01 h during summer. I think that both these Acts are still valid, so that summer time implies standard time. Michael Deckers.
On 2017-12-10 00:21, Paul Eggert wrote:
On 12/09/2017 01:41 PM, Brian Inglis wrote:
Does it matter what is labelled "Standard" by politicians making points?
A bit, but what's more important is common practice among English-speakers.
For what it's worth, a Google search from UCLA today found 20 hits for the search '"Irish Standard Time IST" site:ie', and 9 hits for '"Irish Summer Time IST" site:ie'. The former hits include the Limerick Leader, the Dublin City Council, the Commission for Energy Regulation, and Gaelectric; the latter include Air Accident Investigation Unit Ireland and the School of Physics,Trinity College Dublin. If I change the spelling of the query to find more matches, '"Irish Standard Time" IST site:ie' finds 32 hits, and '"Irish Summer Time IST" site:ie' finds 22 hits. Another example that includes sources outside the Ireland top-level domain: '"Irish Standard Time" IST' has about 25,800 hits, and '"Irish Summer Time" IST' has about 11,100 hits. So these admittedly-crude Google searches suggest that "Irish Standard Time" is the more-common interpretation of IST in Ireland.
Did the same thing against my local google.ca site, and against google.ie for comparison, and report the (very slightly) lower number for every query, also including omitted results, and navigated to the last displayable page of those to get actual matches, as estimated hits are always inflated (sometimes greatly, as in these queries with your last quoted numbers) and may reflect all documents with some words in the query. Some pages discuss IST, but I see some, and assume most, of those are counted in all queries where IST is not included in the quoted search phrase. https://google.{ca,ie}/search?q={"Irish|Irish}+{Summer|Standard}+{Time"+IST|Time+IST"|Time+IST}[+site:ie] base/+omitted (navigating to last displayable page to get actual matches) no site site:ie query 72/ 425 82/198 Irish+Summer+Time+IST 61/ 388 19/ 61 "Irish+Summer+Time"+IST 55/ 322 31/ 77 Irish+Standard+Time+IST 55/ 312 32/111 "Irish+Standard+Time"+IST 53/ 399 9/ 18 "Irish+Summer+Time+IST" 51/ 391 20/ 66 "Irish+Standard+Time+IST" 186/1212 110/277 Summer 161/1025 83/254 Standard My conclusion is that somewhat more writers in general seem to make the natural assumption that "S" is *Summer*, as in the UK and other places where use of /daylight saving/ is uncommon, but more writers on IE sites may know that "S" is *Standard*, from the higher ratios of matches on the quoted phrases. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis wrote:
72/ 425 82/198 Irish+Summer+Time+IST ... 55/ 322 31/ 77 Irish+Standard+Time+IST
These two queries have too many false hits to be useful. For example, here are the top ten hits for the first query (I used google.com from UCLA), preceded by codes indicating what these pages say about the abbreviation IST ("std" means Irish Standard Time, "sum" means Irish Summer Time, "---" means no opinion): std https://en.wikipedia.org/wiki/Time_in_Ireland --- https://www.timeanddate.com/time/zones/ist-ireland --- https://www.timeanddate.com/worldclock/ireland/dublin std http://timebie.com/timezone/irishindia.php std https://www.worldtimeserver.com/time-zones/ist-3/ --- https://www.worldtimeserver.com/current_time_in_IE.aspx --- https://www.worldtimebuddy.com/ireland-dublin-to-ist sum https://www.horlogeparlante.com/time-zone-IST.html sum https://www.sitesworld.com/time/ist-(irish)-to-azost.html std http://www.ireland.com/en-us/about-ireland/once-you-are-here/time-zone/ So, even though this query attempts to count web pages that call IST "Irish Summer Time", its ten highest-ranking pages suggest that "Irish Standard Time" is twice as popular as "Irish Summer Time". Evidently the query is too broad, and Google's algorithms find so many pages on the general subject of Ireland and time and summer that it's double counting pages. We must therefore discard the results of those two queries, as they're not really counting what we are interested in.
no site site:ie query > 61/ 388 19/ 61 "Irish+Summer+Time"+IST ... 55/ 312 32/111 "Irish+Standard+Time"+IST 53/ 399 9/ 18 "Irish+Summer+Time+IST" 51/ 391 20/ 66 "Irish+Standard+Time+IST"
These queries are better, but I get waaay different results from you when I query from UCLA. I get: (no site) site:ie 1 0 "Irish+Summer+Time"+IST 4 1 "Irish+Standard+Time"+IST 1 0 "Irish+Summer+Time+IST" 47 20 "Irish+Standard+Time+IST" and this is an even bigger win for "Irish Standard Time" than the earlier results I posted. Perhaps I'm misunderstanding how you do a query? Here's how I did it: I visited https://www.google.com, and pasted this into the search box: "Irish+Summer+Time"+IST (including all the quotation marks and plus signs), and pressed the "Google Search" button. As noted above I got just one hit (it says "IST" stands for Indian Standard Time, and so doesn't even support the contention that "IST" means Irish Summer Time). I get the same hit if I visited https://www.google.ca. I don't know how to explain the fact that my results differ so much from yours. I should mention that I do not look at hits that Google ordinarily suppresses as very similar, as I've found that these expanded hit counts are not as good an indication of popularity: many sites just republish other site's articles, for example. It's better to try to count count independent sources. The problem of assessing Google hit counts is not limited to Ireland. Several years ago I observed similar issues when estimating the most popular abbreviations Australia. Obvious queries like 'EST "Eastern Standard Time" site:au' did not work, as too many of the hits were polluted by other data (e.g., Australian web pages reporting North American abbreviations). It can be quite tricky to get reliable results.
On 2017-12-10 14:09, Paul Eggert wrote:
Brian Inglis wrote:
72/ 425 82/198 Irish+Summer+Time+IST ... 55/ 322 31/ 77 Irish+Standard+Time+IST These two queries have too many false hits to be useful. For example, here are the top ten hits for the first query (I used google.com from UCLA), preceded by codes indicating what these pages say about the abbreviation IST ("std" means Irish Standard Time, "sum" means Irish Summer Time, "---" means no opinion): std https://en.wikipedia.org/wiki/Time_in_Ireland --- https://www.timeanddate.com/time/zones/ist-ireland --- https://www.timeanddate.com/worldclock/ireland/dublin std http://timebie.com/timezone/irishindia.php std https://www.worldtimeserver.com/time-zones/ist-3/ --- https://www.worldtimeserver.com/current_time_in_IE.aspx --- https://www.worldtimebuddy.com/ireland-dublin-to-ist sum https://www.horlogeparlante.com/time-zone-IST.html sum https://www.sitesworld.com/time/ist-(irish)-to-azost.html std http://www.ireland.com/en-us/about-ireland/once-you-are-here/time-zone/ So, even though this query attempts to count web pages that call IST "Irish Summer Time", its ten highest-ranking pages suggest that "Irish Standard Time" is twice as popular as "Irish Summer Time". Evidently the query is too broad, and Google's algorithms find so many pages on the general subject of Ireland and time and summer that it's double counting pages. We must therefore discard the results of those two queries, as they're not really counting what we are interested in. no site site:ie query > 61/ 388 19/ 61 "Irish+Summer+Time"+IST ... 55/ 312 32/111 "Irish+Standard+Time"+IST 53/ 399 9/ 18 "Irish+Summer+Time+IST" 51/ 391 20/ 66 "Irish+Standard+Time+IST" These queries are better, but I get waaay different results from you when I query from UCLA. I get: (no site) site:ie 1 0 "Irish+Summer+Time"+IST 4 1 "Irish+Standard+Time"+IST 1 0 "Irish+Summer+Time+IST" 47 20 "Irish+Standard+Time+IST" and this is an even bigger win for "Irish Standard Time" than the earlier results I posted. Perhaps I'm misunderstanding how you do a query? Here's how I did it: I visited https://www.google.com, and pasted this into the search box: "Irish+Summer+Time"+IST
I find it easier to deal with and modify the search parameters directly in the URL query string for consistent search results to scrape: just (re-)move the '"'s or paste-select-cut between Summer and Standard, to ensure other parameter settings are unchanged. The URL "+" appears as " " in the search box and vice-versa " " in the search box appears as "+" in the URL. This is in the URL encoding spec for the query string parameter value default application/x-www-form-urlencoded content type, also requiring literal value "+" be URL-/%-encoded as "%2b". That is what those query strings contain instead of "+" or " ", and they appear to be disrupting the search. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis wrote:
The URL "+" appears as " " in the search box and vice-versa " " in the search box appears as "+" in the URL.
With that in mind I currently see this at UCLA: 73 "Irish Summer Time" IST 44 "Irish Standard Time" IST 21 "Irish Summer Time" IST site:ie 31 "Irish Standard time" IST site:ie (Note that these numbers differ from yesterday; also, I've now done this so often that Google is starting to throttle my searches, which is slowing me down.) Superficially looking at these numbers, it appears that IST is more likely to mean "Irish Summer Time" outside Ireland and "Irish Standard Time" within Ireland. But when I look at the actual matches I see the pattern I noticed before: many of the hits for the first query are false matches. For its first 5 hits from unique sites, for example: std https://www.timeanddate.com/time/zones/ist-ireland std https://en.wikipedia.org/wiki/Time_in_Ireland std https://www.worldtimeserver.com/time-zones/ist-3/ sum https://www.horlogeparlante.com/time-zone-IST.html sum https://www.sitesworld.com/time/ist-(irish)-to-ist.html whereas when I do the same for the second query, I see: std https://www.timeanddate.com/time/zones/ist-ireland std http://timebie.com/timezone/irishindia.php std https://en.wikipedia.org/wiki/Time_in_Ireland std https://www.worldtimeserver.com/time-zones/ist-3/ std https://www.worlddata.info/timezones/ist-irish-standard-time.php (Here "std" means the web page says "Irish Standard Time", whereas "sum" means it says "Irish Summer Time".) In other words, the query for "Irish Summer Time" has many hits that say "Irish Standard Time", whereas the query for "Irish Standard Time" is hitting just "Irish Standard Time" pages. So I'm still inclined to think that "Irish Standard Time" is significantly more popular in practice.
Hi, It turns out that currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error). It’s a relatively simple fix, but changing this requires updating ICU, and rolling out the new version to the OS platforms that use it. That is a process that will probably require the better part of a year. As some have observed, Apple provides TZ database updates via a mechanism separate from the usual software release cycle. Such updates of course need to work with the version of ICU installed on customer’s devices. Also, this change requires multiple data updates to Unicode’s Common Locale Data Repository, to align the localized names for Europe/Dublin (for summer and winter) with the new approach. Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust. Meanwhile, clients of ICU are going to have to back this change out manually. Thanks, Debbie
On Dec 9, 2017, at 11:11 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/09/2017 06:00 AM, Mark Davis ☕️ wrote:
I am worried that a significant number of implementations may keel over if handed negative offsets.
So far we've found one specific trivial formatting glitch <https://mm.icann.org/pipermail/tz/2017-December/025696.html>, and one library <https://mm.icann.org/pipermail/tz/2017-December/025694.html> with a debugging assertion about DST offsets that was incorrect. If these examples are typical, then there is little to worry about; if more-significant problems show up, then the tzdata change may need to be reverted.
There is a tension here between trying to support daylight-saving time practice, and trying to keep our code and machines running. Although we want both objectives, they sometimes compete. Here the gain is small (supporting IST as it was intended). If the cost is trivial (a few formatting glitches or debug runs fail until software is corrected) then the gain is worth the cost; if the cost is large (some user programs crash in typical operation) then it's not. So far we've seen only trivial costs.
PS. Howard, that debugging assertion change <https://github.com/HowardHinnant/date/commit/1eeb4cd6522da8c05ccadf3868a076b...> still looks dicey. It still forbids 3-hour DST, for example, even though POSIX TZ strings and the tzfile format both require support for 3-hour DST. POSIX requires support for UT offsets ranging from -24:00 to 24:59:59, so in theory the difference between DST and STD could be in the range -48:59:59 .. 48:59:59. tzdata supports offsets that are way wider, for what it's worth.
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing. I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down. I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
This also broke Java: https://bugs.openjdk.java.net/browse/JDK-8195595 and no doubt also breaks ThreTen-Backport and Joda-Time (I don't have time to test them right now). As I and others have indicated before, this change should not have happened. The likelihood of it breaking something was always very high, and the alleged reality is that it expresses is a fact that is irrelevant to most users (and is disputed anyway). This was change for changes sake. The real problem here is the incessant fiddling with the data. The vast majority of users just want small stable updates representing actual changes in time zones, not the continuous refactoring we've been subjected to in the last few years. Stephen On 18 January 2018 at 20:24, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
It should be noted that a few other countries have also used winter time, according to <https://en.wikipedia.org/wiki/Winter_time_(clock_lag)> (but I agree with the argument that tm_isdst is best defined as indicating whether the clocks are advanced compared to time used for the rest of the year, *not* based on whether the wording of the laws in question defines one time as standard and the other as a variation from it - there's no reason laws need to define one time as standard and the other as a variation at all). -- Joseph S. Myers jsm@polyomino.org.uk
I firmly agree with this. The way to implement Irish standard time is the way it has always been implemented: it is simply the names that would be changed to call one of them standard and one not. I also agree with Stephen Colebourne: the focus should be on small, stable updates, not potentially destabilizing "cleanups". Mark On Thu, Jan 18, 2018 at 2:01 PM, Joseph Myers <jsm@polyomino.org.uk> wrote:
It should be noted that a few other countries have also used winter time, according to <https://en.wikipedia.org/wiki/Winter_time_(clock_lag)> (but I agree with the argument that tm_isdst is best defined as indicating whether the clocks are advanced compared to time used for the rest of the year, *not* based on whether the wording of the laws in question defines one time as standard and the other as a variation from it - there's no reason laws need to define one time as standard and the other as a variation at all).
-- Joseph S. Myers jsm@polyomino.org.uk
The real problem here is the incessant fiddling with the data. The vast majority of users just want small stable updates representing actual changes in time zones, not the continuous refactoring we've been subjected to in the last few years.
I agree completely. Thanks, Debbie
On Jan 18, 2018, at 12:32 PM, Stephen Colebourne <scolebourne@joda.org> wrote:
This also broke Java: https://bugs.openjdk.java.net/browse/JDK-8195595 and no doubt also breaks ThreTen-Backport and Joda-Time (I don't have time to test them right now).
As I and others have indicated before, this change should not have happened. The likelihood of it breaking something was always very high, and the alleged reality is that it expresses is a fact that is irrelevant to most users (and is disputed anyway). This was change for changes sake.
The real problem here is the incessant fiddling with the data. The vast majority of users just want small stable updates representing actual changes in time zones, not the continuous refactoring we've been subjected to in the last few years.
Stephen
On 18 January 2018 at 20:24, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
Stephen Colebourne wrote:
As I and others have indicated before, this change should not have happened. The likelihood of it breaking something was always very high, and the alleged reality is that it expresses is a fact that is irrelevant to most users (and is disputed anyway). This was change for changes sake.
I disagree. This was change in order to be more accurate: if we're offering the isdst flag then it ought to reflect what was actually happening in each jurisdiction. By its nature this flag is less objectively defined than the other outputs of the database, but in this case we have clear evidence that it should be a particular way round. There was indeed a significant chance of the negative SAVE value breaking alternate zic implementations, and now that that's turned out to be the case that's good cause to postpone this correction, or at least the expressing of it in this natural manner. The tzdb does have unusually high stability requirements. But that's not a reason to keep the database forever inaccurate. -zefram
Zefram <zefram@fysh.org> writes:
There was indeed a significant chance of the negative SAVE value breaking alternate zic implementations, and now that that's turned out to be the case that's good cause to postpone this correction, or at least the expressing of it in this natural manner. The tzdb does have unusually high stability requirements. But that's not a reason to keep the database forever inaccurate.
I'm not sure that it's "inaccurate". The question is more about what is the meaning of tm_isdst = 1. It's clear from this discussion that an awful lot of code believes it means "local time is advanced now compared to what it is when tm_isdst = 0". Arguing that it should reflect a legalistic definition of DST, rather than an operational definition, is just an argument; it's not conclusive. FWIW, I share the opinion that this change was misguided. regards, tom lane
On 2018-01-18 19:39:50 (-0500), Tom Lane wrote:
Zefram <zefram@fysh.org> writes:
There was indeed a significant chance of the negative SAVE value breaking alternate zic implementations, and now that that's turned out to be the case that's good cause to postpone this correction, or at least the expressing of it in this natural manner. The tzdb does have unusually high stability requirements. But that's not a reason to keep the database forever inaccurate.
I'm not sure that it's "inaccurate". The question is more about what is the meaning of tm_isdst = 1. It's clear from this discussion that an awful lot of code believes it means "local time is advanced now compared to what it is when tm_isdst = 0". Arguing that it should reflect a legalistic definition of DST, rather than an operational definition, is just an argument; it's not conclusive.
FWIW, I share the opinion that this change was misguided.
I'd go with "premature" rather than "misguided". Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now. Replace the actual change by a comment that the current data is inaccurate pending software being fixed. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Philip Paeps <philip@trouble.is> writes:
On 2018-01-18 19:39:50 (-0500), Tom Lane wrote:
I'm not sure that it's "inaccurate". The question is more about what is the meaning of tm_isdst = 1. It's clear from this discussion that an awful lot of code believes it means "local time is advanced now compared to what it is when tm_isdst = 0". Arguing that it should reflect a legalistic definition of DST, rather than an operational definition, is just an argument; it's not conclusive.
FWIW, I share the opinion that this change was misguided.
I'd go with "premature" rather than "misguided".
How, exactly, will it improve anyone's life to change from "tm_isdst = 1 means that local time is advanced" to "tm_isdst means something, but nobody knows what"? This particular change isn't causing my own software any great grief. (I think. No downstream users of Postgres have been hit by it yet.) On the other hand, I've spent quite a lot of effort over the past couple of years dealing with the random-seeming changes in zone abbreviations, and none of that churn has made anyone's life better that I'm aware of. I think it's past time that the tz database realizes, and acts on, the fact that it's a de facto standard, and whacking around the standard has high costs. There are regular moanings on this list about how $banana_republic changed their DST laws with minimal notice. But when tzdb decides to remove a zone abbreviation with no notice, that's not a problem? I dare to disagree. Similarly, breaking a de facto behavior of the tm_isdst flag isn't something to do lightly, and perhaps not at all. regards, tom lane
From: Tom Lane <tgl@sss.pgh.pa.us> Date: Fri, 19 Jan 2018 01:07:18 -0500 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | How, exactly, will it improve anyone's life to change from "tm_isdst = 1 | means that local time is advanced" to "tm_isdst means something, but | nobody knows what"? The issue is that "means the local time is advanced" is, and always has been, an invalid assumption based uon apparent observed behaviour, rather than any definition. In the past software sometimes assumed it meant "advanced by 1 hour" but that's been broken for so long that it is generally been forgotten now (I hope.) The original use of tm_isdst was an as index into the tzname[] array to allow software to get the correct abbreviation to display. For that purpose it makes not one iota of difference what the offset is for either of the (just two) possible zone names. (Originally of course there was no tzname[] and the names were built into libc, but the purpose was the same, it passed info to asctime() from localtime()). More recently it has also been used in the other direction, as a hint to mktime() which result to pick in the cases of ambiguous localtimes. That's it. Anything using it for any other purpose is broken and ought to be fixed. More than that, as there are (for purpose 1 above) just two values possible (0 and 1) and there is no such limit on the number of different abbreviations which might apply at different times in one of what we call a timezone (that is, a juristiction might decide to have winter time, spring time, summer time, and autumn time, all with different offsets, and give them all different abbreviations), so we really should be deprecating tm_isdst for even this purpose, and rely upon tm_zone and tm_gmtoff instead, which are a much better way to pass the required info out from localtime ... any implementations which are yet to add those fields to struct tm (they were created decades ago - there really is no excuse after all this time) should simply be regarded as broken and unusable. The fundamental problem here is software writers making assumptions about how (human represented) time works - every one of those I have ever seen (that I can think of anyway) has turned out to be wrong, and if there are any that remain, they will break one day (like perhaps 7 days in a week... one day, someone will change that, somewhere!) We already know (yet the assumption is still made) that years are not required to have 12 months, as if you go far enough back into the past, they didn't. Perhaps in the future they won't again (13 is closer to astronomical reality). The answer to this is fairly simple - stop making assumptions, any of them. That includes to stop assuming that there is one "standard" time, and that any other time is some variation (and especially that the variation must have an advanced offset over the "standard" time offset). "Standard" time is simply the time that is agreed it is *now* (at any time of the year) - that's what it means to be a standard. Of course, jurisdictions are free to label one of their offsets as "standard" and another as "summer" or "winter" (or even the absurd "daylight savings") if they want, but those are just names, and should have no bearing on anything other than for display to humans. | On the other hand, I've spent quite a lot of effort over the past couple | of years dealing with the random-seeming changes in zone abbreviations, | and none of that churn has made anyone's life better that I'm aware of. Why? I am not a fan of those changes, I don't seem them accomplishing anything, but if any software breaks because of them, it was already broken, just the breakage was hidden. (Just like the old Y2K issues, where software that assumed 2 digits for a year was always broken, but just happened to work when all that mattered was the second half of the 20th century (CE). Software that assumes 4 digit years is just as broken - there were years before 1000, and there will be years after 9999 (we hope).) The zone name abbreviations should be used for no other purpose than to display to users to give them a slightly more warm and fuzzy feeling that they know (or perhaps don't know) what local time is being shown to them than -0500 does. Anything more than that is simply broken (with the, perhaps, one exception, of e-mail header parsing as long as only those abbreviations that were specified in rfc822 (now mostly deprecated for use) are recognised - and perhaps some other similar uses, where some other standard says what means what -- where what tzdb gives for any abbreviation is 100% irrelevant.) | I think it's past time that the tz database realizes, and acts on, | the fact that it's a de facto standard, and whacking around the | standard has high costs. I agree with that. However, we have the issue that people are simply guessing what what is promised, and what is just changeable data. The abbreviations are, and always have been, subject to change at any time - that they did not frequently change (though there were always some changes) is more just an accident of history than something that can be relied upon. kre ps: in case it is not obvious, I agree with the changes made for Ireland, they're correct, as much as what appears in tm_isdst is ever "correct". I'm not sure I'd even bother delaying the effect, and certainly not for as long as a year - I could understand backing them out of 2018b, but they should be back again in 2018c, and remain after that. I'm guessing that c is likely to appear around March sometime, so all you people with software that is abusing the field, or making assumptions about it, have a couple of months to get it fixed. That is, just stop using it at all. For localised translations of the zone abbreviations, use the zone (America/New_York or whatever it happens to be) with tm_zone field as a key (or perhaps tm_gmtoff) to look up the localised replacement for tm_zone.
On Jan 19, 2018, at 2:22 AM, Robert Elz <kre@munnari.OZ.AU> wrote:
From: Tom Lane <tgl@sss.pgh.pa.us> Date: Fri, 19 Jan 2018 01:07:18 -0500 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time
| How, exactly, will it improve anyone's life to change from "tm_isdst = 1 | means that local time is advanced" to "tm_isdst means something, but | nobody knows what"?
The issue is that "means the local time is advanced" is, and always has been, an invalid assumption based uon apparent observed behaviour, rather than any definition.
In the past software sometimes assumed it meant "advanced by 1 hour" but that's been broken for so long that it is generally been forgotten now (I hope.)
The original use of tm_isdst was an as index into the tzname[] array to allow software to get the correct abbreviation to display. ...
I can believe that this is one usage that has appeared in some code at some time. "Well defined semantics" requires having a meaning that's clearly and consistently documented and well understood to be the agreed to meaning. It's not clear that applies to the is_dst field. Does POSIX say anything? A sample from a couple of manpages shows one (Mac OS, which takes it from BSD) describing it as "is summer time in effect" while Linux says "daylight savings time". These both match "local time is advanced". So it seems to me that calling "local time is advanced" an "invalid assumption" is not justified. Perhaps it would be valid to call it overly optimistic since it's based on informal definitions (manpages from certain OS implementations) but there clearly is non-zero basis for applying that definition. paul
| From: <Paul.Koning@dell.com> | Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | Date: Fri, 19 Jan 2018 14:58:37 +0000 | I can believe that this is one usage that has appeared in some | code at some time. I am not sure what you are getting at here, but the original use of the field was to communicate from localtime() to date (1) [not asctime(), I forgot it does not use the zone name] which abbreviation it should use when printing the date/time. | "Well defined semantics" requires having a meaning that's clearly and | consistently documented and well understood to be the agreed to meaning. Yes. | It's not clear that applies to the is_dst field. Does POSIX say anything? Posix: The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available. But POSIX is largely derived from System V, and its time handling (and the TZ env var setting that is supposed to define it) has always been weak. This really says nothing about what it means, or how it can be used, or anything else - it relies on people "just knowing" which once those who cared did, but no longer it seems. | These both match "local time is advanced". No, they match POSIX (more or less) with few details, and there is nothing at all about "advanced" - as Paul mentioned earlier, "Daylight Savings" can be negative. A possible future (if quite unlikely) example... It is often wondered (especially by people in south east Australia) why Queensland doesn't implement summer time - at least in the (most populous area) in the south east of the state. While it is somethimes discussed, it has never happened (not even a trial, as was done in Western Australia) - the reason I think is that first, the area concerned is already in "negative" time - ie: it lies east of the 150 degree longitude line (so the sun is overhead earlier than noon), which you would think would be a bigger argument for summer time, but turns out to be the opposite. Second, in that area, in summer, what happens, is that the longer days (even southern Qld is still at a fairly small latitude, so the change is not huge in any case) are almost all earlier sunrise, there is only a limited shift in sunset (or at least it seems that way), and to make things worse, it is also (what would be in the tropics) monsoon season - during much of the summer months it tends to get very gloomy around 17:30 (because of cloud cover) and rain a lot. Hardly useful to make that happen at 18:30 instead... Rather, people have adapted to a different lifestyle than most of the rest of us (which amazed me when I first went to live in that area, many many years ago now) - where the "after work" recreation time is in the early morning - people get up at 04:00 or 05:00 and go swimming/ surfing/fishing/golfing/... whatever, and then go to work (or school) after that (normal working hours). So, given it gets light, early in summer, what would be more useful would be to make it be sunrise at 03:30 or 04:00 instead of 04:30, so there was extra recreation time available. So a summer period of an hour (or 30 minutes, or something) of negative summer time would not be an outlandish thing to happen there. I don't expect it, I doubt it has ever even been suggested, but stranger things have happened. Once again, everyone should stop making assumptions about how clock time works, or should work. The assumptions are all wrong (now, or will be in the future), and embedding them in lots of code does not make them any more likely to become correct. kre
On 01/19/2018 06:58 AM, Paul.Koning@dell.com wrote:
Does POSIX say anything?
POSIX uses different phrases in different places to talk about tm_isdst and related notions. In its discussion of the TZ environment variable: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... it talks about "the alternative (dst -such as Daylight Savings Time) timezone". In its discussion of time.h: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html it says "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available."; this is language taken directly from the ISO C standard, section 7.27.1. The language of the C standard is older, and the POSIX language for TZ was added later, I suppose by a committee that concluded that calling it "the alternative timezone" would allow more freedom to implementations for situations where calling it "daylight saving" was inappropriate. Robert Elz's summary of what tm_isdst was actually used for matches my impression as well.
On Fri, Jan 19, 2018, at 02:22, Robert Elz wrote:
From: Tom Lane <tgl@sss.pgh.pa.us> Date: Fri, 19 Jan 2018 01:07:18 -0500 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time
| How, exactly, will it improve anyone's life to change from "tm_isdst = 1 | means that local time is advanced" to "tm_isdst means something, but | nobody knows what"?
The issue is that "means the local time is advanced" is, and always has been, an invalid assumption based uon apparent observed behaviour, rather than any definition.
It's also based on the plain english meaning of the term "DST" and the words to which the abbreviation expands. Daylight is not being "saved" by turning the clock back. If it were called tm_isalt (to match the "altzone" global from System V, perhaps), your argument might be more valid, but this name has a clear English meaning, and there is no historical basis (as there is for tm_mon) to justify the failure to match what people expect from reading it.
| From: Random832 <random832@fastmail.com> | Date: Fri, 19 Jan 2018 11:12:28 -0500 | Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | It's also based on the plain english meaning of the term "DST" | and the words to which the abbreviation expands. Since the plain English meaning of those words is nonsense in any case, that hardly matters. | Daylight is not being "saved" by turning the clock back. Daylight isn't being saved in any case, the period of daylight is just being moved with respect to what the clock shows. The amount of daylight available is exactly the same. This would be kind of like moving a dollar from your right pocket to the left, and counting that as "saved". What was supposed to be saved (and which has I believe proved to be largely ineffective) was power, not daylight, and given the right circumstances, if that were to be possible, any clock adjustment might turn out to be the right one. | If it were called tm_isalt (to match the "altzone" global from System V, It was invented (the name) long before System V (or System anything) was even a dream. There was no "altzone" to reference, the abbreviations were compiled in somewhere. There's no question, when created, it was meant to indicate that (US) summer time (daylight savings time) was in effect, and the 'D' rather that 'S' forms of the tz abbreviations should be used. | but this name has a clear English meaning, You're assuming that daylight savings time means that the clocks must be put forward (which has been historically true, but there's no logical, let alone "plain English" reason for that - it is just how it has been). Once again, avoid assuming that you know how clock time works, you don't (nor do I, nor does anyone else). kre
On Fri 2018-01-19T14:22:18+0700 Robert Elz hath writ:
More than that, as there are (for purpose 1 above) just two values possible (0 and 1) and there is no such limit on the number of different abbreviations which might apply at different times in one of what we call a timezone (that is, a juristiction might decide to have winter time, spring time, summer time, and autumn time, all with different offsets, and give them all different abbreviations), so we really should be deprecating tm_isdst for even this purpose, and rely upon tm_zone and tm_gmtoff instead, which are a much better way to pass the required info out from localtime ... any implementations which are yet to add those fields to struct tm (they were created decades ago - there really is no excuse after all this time) should simply be regarded as broken and unusable.
The original POSIX draft was IEEE Std 1003.1 issued for Trial-Use in April 1986, and the final version was IEEE Standard Portable Operating System Interface for Computer Environments (IEEE Std 1003.1-1988) in September 1988. Those make it quite clear that the POSIX committee included the System V tm_isdst merely to accommodate its ongoing use even though that scheme was hard-coded to apply only to US usage. It is a dark moment in history that the POSIX committee did not wholeheartedly support the tz project that already then existed. Palm Springs California is another example where that simple model was always broken. The shadow of Mt. San Jacinto brings darkness very early in the winter months. In 1946 the chamber of commerce decided to put the clocks of Palm Springs forward by an hour in the winter. https://www.desertsun.com/story/life/2017/12/27/palm-springs-struggle-daylig... -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Fri, 19 Jan 2018, Robert Elz wrote:
"Standard" time is simply the time that is agreed it is *now* (at any time of the year) - that's what it means to be a standard.
That's essentially why I think tm_isdst should be based on something other than the notion of one time offset being standard and another being a variant on that. The laws establishing time offsets have the function of determining the offset applicable for legal purposes at any given time, not the function of determining tm_isdst. Just because the law happens to be worded as "the offset is X, except at these times when it's Y", or to give a name involving "standard time" to one choice of offset, should not be considered of semantic significance; the law had to choose some part of the year to be X and some part to be Y, or if naming the offsets had to come up with different names for them, but the particular choice of which is X and which is Y is just an arbitrary choice in drafting the law. -- Joseph S. Myers jsm@polyomino.org.uk
Date: Sat, 20 Jan 2018 01:39:50 +0000 (UTC) From: Joseph Myers <jsm@polyomino.org.uk> Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | That's essentially why I think tm_isdst should be based on something | other than the notion of one time offset being standard and another | being a variant on that. I don't disagree with anything that you say, but I'd go one step further, and simply deprecate tm_isdst - it no longer serves any necessary useful purpose at all (and anyone who believes it does is not understanding its purpose). [Those who still need it for its original purpose should adopt tm_zone and tm_gmtoff instead.] We can't just delete it, as it is in C and POSIX stds, but we can tell people not to use it. kre
On Jan 20, 10:45am, kre@munnari.OZ.AU (Robert Elz) wrote: -- Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | I don't disagree with anything that you say, but I'd go one step | further, and simply deprecate tm_isdst - it no longer serves any | necessary useful purpose at all (and anyone who believes it does | is not understanding its purpose). [Those who still need it for | its original purpose should adopt tm_zone and tm_gmtoff instead.] If we are going to standardize those two, I think that tm_zone should become an array instead of a pointer, or at least the "char *" pointer lifetime and ownership should be defined. Also if we are changing tm_zone, then tm_gmtoff should be an int not a long. Does anyone remember why it was chosen to be a long? 16 bit integers on pdp 11? Does "struct tm" go that far back? christos
On Jan 19, 2018, at 8:10 PM, Christos Zoulas <christos@zoulas.com> wrote:
If we are going to standardize those two, I think that tm_zone should become an array instead of a pointer,
That breaks binary compatibility on any OS that has tm_zone and documents it; that matters, at minimum, with any OS from Cupertino, so I very much doubt Apple will pick that up.
or at least the "char *" pointer lifetime and ownership should be defined.
That's more work, but it doesn't break binary compatibility.
Also if we are changing tm_zone, then tm_gmtoff should be an int not a long.
Same binary-compatibility problem, at least on LP64 platforms.
Does anyone remember why it was chosen to be a long? 16 bit integers on pdp 11? Does "struct tm" go that far back?
struct tm goes all the way back to, at minimum, V7, which definitely ran on PDP-11's. tm_zone doesn't go back as far, and the PDP-11 may not have been a concern at that point, but there may have still have been ILP16 or I16LP32 platforms at the time.
On 2018-01-19 22:01, Guy Harris wrote:
On Jan 19, 2018, at 8:10 PM, Christos Zoulas <christos@zoulas.com> wrote:
Also if we are changing tm_zone, then tm_gmtoff should be an int not a long. Same binary-compatibility problem, at least on LP64 platforms. Does anyone remember why it was chosen to be a long? 16 bit integers on pdp 11? Does "struct tm" go that far back? struct tm goes all the way back to, at minimum, V7, which definitely ran on PDP-11's. tm_zone doesn't go back as far, and the PDP-11 may not have been a concern at that point, but there may have still have been ILP16 or I16LP32 platforms at the time.
PCs pre 68K and pre 386 protected mode DOS "extenders". -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Jan 19, 2018, at 10:21 PM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
PCs pre 68K and pre 386 protected mode DOS "extenders".
OK, let me rephrase that as "*UN*X* ILP16 or I16LP32 platforms..."; "struct tm" was mainly a UN*Xism at that point.
Christos Zoulas wrote:
If we are going to standardize those two, I think that tm_zone should become an array instead of a pointer, or at least the "char *" pointer lifetime and ownership should be defined.
This is all doable. An API standard could allow tm_zone to be either a char array or a char const * pointer, with applications not supposed to care. This would allow existing implementations and would allow the alternative implementation that you're thinking of. If tm_zone is a pointer, its lifetime would be that of the corresponding timezone_t object (for the new API with localtime_rz etc.) for until the next call to tzset (either explicit or implied) with a different TZ value (for the traditional API with localtime_r etc.).
if we are changing tm_zone, then tm_gmtoff should be an int not a long. Does anyone remember why it was chosen to be a long? 16 bit integers on pdp 11? Does "struct tm" go that far back?
When tm_gmtoff was designed, 'long' was the only portable type that was guaranteed to be wide enough to hold practical UT offsets. To standardize tm_gmtoff we should probably invent a typedef for it, presumably 'gmtoff_t'. That way, new implementations could use (say) 'int_least32_t' for it if they wanted to.
From: Paul Eggert <eggert@cs.ucla.edu> Date: Sat, 20 Jan 2018 12:49:01 -0800 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time | An API standard could allow tm_zone to be either a char | array or a char const * pointer, While it is obviously possible, I'd suggest not the array form -- coming up with something that is big enough to withstand possible future abbreviations, without ABI problems, or being forced to arbitrarily limit their lengths to meet the lowest common value of what the various implementations have chosen would be just too hard to live with. (And having implementations make it be absurdly large, like 128 or something, just in case, would be just plain wasteful.) I'd just forget that and assume it will be a pointer (to a const char *). | If tm_zone is a pointer, its lifetime | would be that of the corresponding timezone_t object Agreed. For the majority of programs that don't call tzset, that means for the lifetime of the program. For those that do, it is easy to manage. kre
On Sun, Jan 21, 2018, at 08:07, Robert Elz wrote:
From: Paul Eggert <eggert@cs.ucla.edu> Date: Sat, 20 Jan 2018 12:49:01 -0800 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time
| An API standard could allow tm_zone to be either a char | array or a char const * pointer,
While it is obviously possible, I'd suggest not the array form -- coming up with something that is big enough to withstand possible future abbreviations, without ABI problems, or being forced to arbitrarily limit their lengths to meet the lowest common value of what the various implementations have chosen would be just too hard to live with. (And having implementations make it be absurdly large, like 128 or something, just in case, would be just plain wasteful.)
What about not directly exposing tm_zone at all? Just have a function that takes a struct tm * and provides a timezone name string based on examining an implementation-defined selection of data members of the struct. [In fact, this function already exists and is called strftime.] You could, for example, have the struct tm contain an integer identifier (which won't be reused once the string is unloaded), and once the string is "lifetimed out" the function will simply return UTC+NN:NN instead. The actual strings could live in a global data structure with the least recently used string freed whenever more space is needed.
On 2018-01-22 11:10, Random832 wrote:
On Sun, Jan 21, 2018, at 08:07, Robert Elz wrote:
From: Paul Eggert <eggert@cs.ucla.edu> Date: Sat, 20 Jan 2018 12:49:01 -0800 Subject: Re: [tz] Irish Standard Time vs Irish Summer Time
| An API standard could allow tm_zone to be either a char | array or a char const * pointer,
While it is obviously possible, I'd suggest not the array form -- coming up with something that is big enough to withstand possible future abbreviations, without ABI problems, or being forced to arbitrarily limit their lengths to meet the lowest common value of what the various implementations have chosen would be just too hard to live with. (And having implementations make it be absurdly large, like 128 or something, just in case, would be just plain wasteful.)
What about not directly exposing tm_zone at all? Just have a function that takes a struct tm * and provides a timezone name string based on examining an implementation-defined selection of data members of the struct. [In fact, this function already exists and is called strftime.]
You could, for example, have the struct tm contain an integer identifier (which won't be reused once the string is unloaded), and once the string is "lifetimed out" the function will simply return UTC+NN:NN instead. The actual strings could live in a global data structure with the least recently used string freed whenever more space is needed.
Donwstream libraries seem to use either the BSD or GNU definitions of tm_gmtoff and tm_zone, combined with localization using ICU, or their platform's approach. While most distros distribute tzdata, few distribute tzcode, providing only zic and zdump utilities. Their upstream libraries use internationalization interfaces, and selectively apply tzcode patches with their own variations to handle i18n and l14n. These libraries and their data have been stable for decades, so it seems unlikely that innovations impacting their core ABI would be adopted, as we have seen with recent data changes.
From recent data issues, we have seen that handling i14n and l14n compatibly overrides legal correctness, and we should pay close attention to those concerns expressed.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Sunday, January 21 2018, "Robert Elz" wrote to "eggert@cs.ucla.edu, tz@iana.org, jsm@polyomino.org.uk" saying:
| If tm_zone is a pointer, its lifetime | would be that of the corresponding timezone_t object
Agreed. For the majority of programs that don't call tzset, that means for the lifetime of the program. For those that do, it is easy to manage.
This corresponds to the definition of strftime "%Z" in POSIX: If a struct tm broken-down time structure is created by localtime() or localtime_r(), or modified by mktime(), and the value of TZ is subsequently modified, the results of the %Z and %z strftime() conversion specifiers are undefined, when strftime() is called with such a broken-down time structure. http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html The reason it's "undefined" (as opposed to "unspecified") is specifically to handle the case where struct tm has tm_zone, and %Z is populated from it. -- Jonathan Lennox lennox@cs.columbia.edu
On 2018-01-19 18:39, Joseph Myers wrote:
On Fri, 19 Jan 2018, Robert Elz wrote:
"Standard" time is simply the time that is agreed it is *now* (at any time of the year) - that's what it means to be a standard.
That's essentially why I think tm_isdst should be based on something other than the notion of one time offset being standard and another being a variant on that. The laws establishing time offsets have the function of determining the offset applicable for legal purposes at any given time, not the function of determining tm_isdst. Just because the law happens to be worded as "the offset is X, except at these times when it's Y", or to give a name involving "standard time" to one choice of offset, should not be considered of semantic significance; the law had to choose some part of the year to be X and some part to be Y, or if naming the offsets had to come up with different names for them, but the particular choice of which is X and which is Y is just an arbitrary choice in drafting the law.
Set when last transition increased offset, clear when last transition reduced offset? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis wrote:
Set when last transition increased offset, clear when last transition reduced offset?
An interesting idea, but if taken literally it would depart from the original intent of tm_isdst in too many cases. For example, it would mean Africa/Lagos would currently have tm_isdst set, because Nigeria's last transition increased the UT offset, when it switched from local mean time to standard time in 1919. I agree with Robert Elz that tm_isdst is vestigial, in the sense that nowadays application uses of it are typically unnecessary or even incorrect. The same goes for its many counterparts in Java, such as the getRawOffset, getDSTSavings, observesDaylightTime, useDaylightTime, and inDaylightTime methods of the java.util.TimeZone class. In hindsight, all these interfaces are mistakes: they attempt to shoehorn civil-timekeeping practices into boxes that too often don't fit, and applications don't really need the interfaces directly anyway. This is underscored by the nature of the bug reports reported so far for this problem: most of them are for test suites (that is, they're testing vestigial interfaces and so are relatively unimportant in and of themselves), and the only application-level bug report showed that the application was clearly wrong in its use of tm_isdst. All this being said, tzdb can't simply ignore these vestigial interfaces, as so much software uses them (albeit incorrectly).
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.) There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time. The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
On 2018-01-19 00:14:16 (-0800), Paul Eggert wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
This patch looks good. Thank you. To avoid churn for consumers of the tzdb, could you please warn the list a few days before you intend to release a version so it can be sanity checked before the release? 2018a and 2018b should probably have been 2018a-rc1 and 2018a-rc2 (though I don't think they need Git tags to reflect that) and after the discussions we just had, finally 2018a could have been released.
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former.
Likewise. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On Fri, 19 Jan 2018, Philip Paeps wrote:
On 2018-01-19 00:14:16 (-0800), Paul Eggert wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
This patch looks good. Thank you.
To avoid churn for consumers of the tzdb, could you please warn the list a few days before you intend to release a version so it can be sanity checked before the release?
As Paul now uses Git (I know, for experimental purposes), it would not be too difficult to set up some build checks with Travis. Anytime he pushes something, it can sanity checks. For example, run "make" and see whether it compiles (which would for example have caught the pacificnew issue). I'd be more than happy to have a look at this, and prepare a PR for it. If anybody has other sanity checks that can be automatically run, that would make it less likely that "trivial" issues like this would crop up. Paul, I also think it would be good if you could "git tag" each release when you make them, instead of just having the "Release 2018b" text. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug
On 01/19/2018 04:00 AM, Derick Rethans wrote:
As Paul now uses Git (I know, for experimental purposes), it would not be too difficult to set up some build checks with Travis. Anytime he pushes something, it can sanity checks.
Yes, that's always been the intent of the GitHub version. Its master branch is supposed to be always suitable for external testing. To help emphasize that, I'm no longer calling it "the experimental version" and am now calling it "the development version". I hope the kerfuffle about Irish time helps to spur people to use the development version to expose problems earlier, rather than wait until after a release. That will help avoid similar problems in the future. Although the tzdb package has several internal tests that I run regularly and run as part of the release-publication process, it's not realistic to expect these tests to catch all potential problems with downstream users.
it would be good if you could "git tag" each release when you make them, instead of just having the "Release 2018b" text.
This is being done, and releases starting from 2012e all have tags.
On 01/19/2018 12:42 AM, Philip Paeps wrote:
To avoid churn for consumers of the tzdb, could you please warn the list a few days before you intend to release a version so it can be sanity checked before the release?
I'm intending to release 2018c in a few days, so please consider this email to be notification of an impending release. I'd release 2018c today, except I want to give the recently-circulated patches time for people to think about them.
2018a and 2018b should probably have been 2018a-rc1 and 2018a-rc2 (though I don't think they need Git tags to reflect that) and after the discussions we just had, finally 2018a could have been released.
Both 2018a and 2018b were intended to be full releases. The release process takes some time, though, and this time around problem reports came in during the release process that convinced me not to announce the releases. Had I known about the problems in advance, I would not have tagged the releases. I'd rather not support the bureacracy of -rc* tags, as the repository is designed to support continuous testing and I'd rather have downstream users test continuously.
Thanks for the revert, however I disagree that it is an appropriate change to make in general. The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557 I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say. Stephen On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time.
The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
On 2018-01-19 08:44:12 (+0000), Stephen Colebourne wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Actually, "in the fall, clocks fall back" is a way at least some people remember what to do with their clocks when going in or out of DST. I have no idea where I first heard that though. I think the "average man in the street" anywhere in the world that observes DST merely wishes people would stop messing with his clocks every time it happens. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On 2018-01-19 01:54, Philip Paeps wrote:
On 2018-01-19 08:44:12 (+0000), Stephen Colebourne wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Actually, "in the fall, clocks fall back" is a way at least some people remember what to do with their clocks when going in or out of DST. I have no idea where I first heard that though.
Somewhere in the States? As most places in the world say localized versions of "Summer time", the inverse may be "Winter time", true time, offical time, normal time, or just [region] time.
I think the "average man in the street" anywhere in the world that observes DST merely wishes people would stop messing with his clocks every time it happens.
Places with few extra daylight hours in summer probably appreciate the addition, whereas places near the tropics and circles wish politicians would stop messing with clocks for no useful purpose. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
I've been trying to work out when and how to chime in, but I think Stephen's post is closest to my view. As far as I can tell, Noda Time will technically work. ZonedDateTime.IsDaylightSavingTime() method will return true for the winter and false for the summer (from whenever this takes effect, of course - I haven't checked). That will surprise developers who aren't aware of this change, and won't surprise developers who *are* aware of this change. I don't think I know a better solution though. At a very, very simplistic level, I'd say it's worth weighing up the pros and cons: Option 1: Keep the change Pros: - "Technically correct" (maybe - I'll assume it is for the sake of this discussion) - Doesn't revert anything Cons: - Breaks a lot of code right now Option 2: Defer the change Pros: - Existing software keeps working as expected by most users and developers Cons: - "Technical correctness" is delayed - Anything which was changed to support 2018a with a bad Irish-specific fix may get confused again - We'll never really know when it's safe to apply the change Option 3: Revert the change forever, possibly formalizing this Pros: - Existing software keeps working as expected by most users and developers Cons: - At odds with technical correctness For me the "keeping working as expected by most users and developers" is the most important part... even if developers fix software to "work" and display things according to Irish legislation, my guess is that it will confuse a lot of *real users*. Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness... Jon On 19 January 2018 at 08:44, Stephen Colebourne <scolebourne@joda.org> wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Stephen
On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the
change
out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time.
The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
I agree, but would go further. I don't think the change did increase "technical correctness", nor is it mandated by Irish legislation. Without negative offsets, it is no problem for any implementation to have the name "Irish Standard Time" for what they use in the summer (UTC+01:00), and the name "Greenwich Mean Time" for what they use in the winter (UTC+0). Mark Mark On Fri, Jan 19, 2018 at 10:24 AM, Jon Skeet <skeet@pobox.com> wrote:
I've been trying to work out when and how to chime in, but I think Stephen's post is closest to my view.
As far as I can tell, Noda Time will technically work. ZonedDateTime.IsDaylightSavingTime() method will return true for the winter and false for the summer (from whenever this takes effect, of course - I haven't checked). That will surprise developers who aren't aware of this change, and won't surprise developers who *are* aware of this change. I don't think I know a better solution though.
At a very, very simplistic level, I'd say it's worth weighing up the pros and cons:
Option 1: Keep the change Pros: - "Technically correct" (maybe - I'll assume it is for the sake of this discussion) - Doesn't revert anything
Cons: - Breaks a lot of code right now
Option 2: Defer the change Pros: - Existing software keeps working as expected by most users and developers
Cons: - "Technical correctness" is delayed - Anything which was changed to support 2018a with a bad Irish-specific fix may get confused again - We'll never really know when it's safe to apply the change
Option 3: Revert the change forever, possibly formalizing this Pros: - Existing software keeps working as expected by most users and developers
Cons: - At odds with technical correctness
For me the "keeping working as expected by most users and developers" is the most important part... even if developers fix software to "work" and display things according to Irish legislation, my guess is that it will confuse a lot of *real users*.
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
Jon
On 19 January 2018 at 08:44, Stephen Colebourne <scolebourne@joda.org> wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Stephen
On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the
change
out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time.
The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
My impression is that tzdb has always tried to be historically correct and this change falls into that category. If we constrain Paul or any other maintainer to changes which won't break any currently used implementations then maybe we lose the possibility of having something that as closely as possible matches current knowledge - whatever our personal opinions of what forward/back means. Would it be more reasonable to derive a 'sanitized' tzdb from the 'real' tzdb which can satisfy the requirements of extant implementations. It would even be possible to have multiple such derivations if conflicting requirements appear. This could also be generated automatically I presume for each release. This shouldn't fall on Paul. The responsibility for testing software lies with the software owners. On 1/19/18 13:15, Mark Davis ☕️ wrote:
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
I agree, but would go further. I don't think the change did increase "technical correctness", nor is it mandated by Irish legislation. Without negative offsets, it is no problem for any implementation to have the name "Irish Standard Time" for what they use in the summer (UTC+01:00), and the name "Greenwich Mean Time" for what they use in the winter (UTC+0).
Mark
Mark //
On Fri, Jan 19, 2018 at 10:24 AM, Jon Skeet <skeet@pobox.com <mailto:skeet@pobox.com>> wrote:
I've been trying to work out when and how to chime in, but I think Stephen's post is closest to my view.
As far as I can tell, Noda Time will technically work. ZonedDateTime.IsDaylightSavingTime() method will return true for the winter and false for the summer (from whenever this takes effect, of course - I haven't checked). That will surprise developers who aren't aware of this change, and won't surprise developers who /are/ aware of this change. I don't think I know a better solution though.
At a very, very simplistic level, I'd say it's worth weighing up the pros and cons:
Option 1: Keep the change Pros: - "Technically correct" (maybe - I'll assume it is for the sake of this discussion) - Doesn't revert anything
Cons: - Breaks a lot of code right now
Option 2: Defer the change Pros: - Existing software keeps working as expected by most users and developers
Cons: - "Technical correctness" is delayed - Anything which was changed to support 2018a with a bad Irish-specific fix may get confused again - We'll never really know when it's safe to apply the change
Option 3: Revert the change forever, possibly formalizing this Pros: - Existing software keeps working as expected by most users and developers
Cons: - At odds with technical correctness
For me the "keeping working as expected by most users and developers" is the most important part... even if developers fix software to "work" and display things according to Irish legislation, my guess is that it will confuse a lot of /real users/.
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
Jon
On 19 January 2018 at 08:44, Stephen Colebourne <scolebourne@joda.org <mailto:scolebourne@joda.org>> wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557 <https://tools.ietf.org/html/rfc6557>
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Stephen
On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote: > Philip Paeps wrote: >> >> Given the number of things this break, I would suggest backing the change >> out for now but pointing out in NEWS that it will come back say one year >> from now. >> >> Replace the actual change by a comment that the current data is inaccurate >> pending software being fixed. > > > Thanks, this sounds like a good way to go. Proposed patch attached, and > installed into the development version on GitHub. Presumably there should be > a 2018c release quite soon, to get this temporary workaround out the door. > (2018b has been prepared and published but not announced, since the problems > with ICU and OpenJDK became apparent during the post-publication process.) > > There is a conflict between the goals of "let's not break anything" and > "let's match civil timekeeping practice". I lean towards doing the latter as > long as it doesn't cause too much trouble for the former. Here it seems like > there is some trouble with ICU and OpenJDK, so delay seems advisable until > fixes can be prepared. That being said, I don't want to wait indefinitely > for these fixes. This is not a tzdb-specific issue, since POSIX requires > support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current > Irish rules), which means that applications that reject negative DST are not > portable to standard platforms configured for Irish time. > > The proposed patch continues to use the "IST is standard time" approach for > Irish timestamps between October 1968 and October 1971, but I assume that's > OK since that's what we did before.
There's a huge difference between "this change might possibly break some implementations" and "we *know* this change will break some very widespread implementations" or even "we *know* this change will break implementations which now have fixes in place but where those fixes certainly won't have been universally adopted". There's also a huge difference between making a change for correctness that will have a definite benefit to users, and making a change purely for *technical* correctness with no palpable user benefit. (And this is presupposing that it *is* more correct - as Mark said, it's not clear that's even the case.) Any change, at any time, where we know it will break real users - whether that's because of a lack of testing of scenarios which haven't happened before or not - should only be undertaken when there are *massively* positive benefits for other users, IMO. If someone's phone breaks, how much do you think they care whether it's because of an app developer, a library developer, an OS developer, or the data provider? Jon On 19 January 2018 at 18:48, Michael Douglass <mikeadouglass@gmail.com> wrote:
My impression is that tzdb has always tried to be historically correct and this change falls into that category.
If we constrain Paul or any other maintainer to changes which won't break any currently used implementations then maybe we lose the possibility of having something that as closely as possible matches current knowledge - whatever our personal opinions of what forward/back means.
Would it be more reasonable to derive a 'sanitized' tzdb from the 'real' tzdb which can satisfy the requirements of extant implementations. It would even be possible to have multiple such derivations if conflicting requirements appear. This could also be generated automatically I presume for each release.
This shouldn't fall on Paul. The responsibility for testing software lies with the software owners.
On 1/19/18 13:15, Mark Davis ☕️ wrote:
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
I agree, but would go further. I don't think the change did increase "technical correctness", nor is it mandated by Irish legislation. Without negative offsets, it is no problem for any implementation to have the name "Irish Standard Time" for what they use in the summer (UTC+01:00), and the name "Greenwich Mean Time" for what they use in the winter (UTC+0).
Mark
Mark
On Fri, Jan 19, 2018 at 10:24 AM, Jon Skeet <skeet@pobox.com> wrote:
I've been trying to work out when and how to chime in, but I think Stephen's post is closest to my view.
As far as I can tell, Noda Time will technically work. ZonedDateTime.IsDaylightSavingTime() method will return true for the winter and false for the summer (from whenever this takes effect, of course - I haven't checked). That will surprise developers who aren't aware of this change, and won't surprise developers who *are* aware of this change. I don't think I know a better solution though.
At a very, very simplistic level, I'd say it's worth weighing up the pros and cons:
Option 1: Keep the change Pros: - "Technically correct" (maybe - I'll assume it is for the sake of this discussion) - Doesn't revert anything
Cons: - Breaks a lot of code right now
Option 2: Defer the change Pros: - Existing software keeps working as expected by most users and developers
Cons: - "Technical correctness" is delayed - Anything which was changed to support 2018a with a bad Irish-specific fix may get confused again - We'll never really know when it's safe to apply the change
Option 3: Revert the change forever, possibly formalizing this Pros: - Existing software keeps working as expected by most users and developers
Cons: - At odds with technical correctness
For me the "keeping working as expected by most users and developers" is the most important part... even if developers fix software to "work" and display things according to Irish legislation, my guess is that it will confuse a lot of *real users*.
Basically, I value "practical correctness" much, much, much higher than "technical correctness" here - I would far prefer the Irish legislation to change in order to get technical correctness...
Jon
On 19 January 2018 at 08:44, Stephen Colebourne <scolebourne@joda.org> wrote:
Thanks for the revert, however I disagree that it is an appropriate change to make in general.
The IANA charter of TZDB says: "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." https://tools.ietf.org/html/rfc6557
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter, I think they believe their clocks go forward in summer. More specifically, the project is about de facto time as perceived by the masses, not what the legal documents say.
Stephen
On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the
change
out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time.
The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
On 01/19/2018 10:48 AM, Michael Douglass wrote:
Would it be more reasonable to derive a 'sanitized' tzdb from the 'real' tzdb which can satisfy the requirements of extant implementations.
It should be easy to do that automatically, at least for the Irish case. That's something we could install into the development version after 2018c comes out, assuming somebody writes the code.
On 01/19/2018 12:44 AM, Stephen Colebourne wrote:
I do not believe that the "average man on the street" in Ireland thinks their clocks go back in winter
This point was discussed before the changes were installed in December. As I recall, it appears that in Ireland the more-common usage agrees with the legal usage, which is that IST is called "Irish Standard Time" and is the standard time that is observed for most of the year, and that GMT is observed during winter. I recall looking at a number of English-language sources about this. For more, please see the thread starting here: https://mm.icann.org/pipermail/tz/2017-December/025682.html
For those not paying full attention, this patch did not revert all of the changes! Instead it effectively disabled the negative SAVE value in the "Rule" section by not using it from the "Zone" section. I have investigated the impact of negative SAVE values on ThreeTen-Backport - http://www.threeten.org/threetenbp/ - which is basically a forked version of some of the OpenJDK code. The good news is that the data files are still parsed and timestamps are still correct. The bad news is that negative SAVE values completely screw up Java APIs that have existed for 20 years. ThreeTen-Backport and OpenJDK have the methods: ZoneRules.isDaylightSavings(Instant) ZoneRules.getDaylightSavings(Instant) https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneRules.html#getD... With the Irish changes, the former method now returns true in winter and false in summer. And the latter returns a negative offset in winter and zero in summer. The problem is that there is lots of underlying code in other parts of the JDK (which can't be changed as its been that way for 20 years) that takes a DST boolean flag: TimeZone.getDisplayName(boolean daylight, int style, Locale locale) https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getDisplay... This method has expected the daylight flag to be true in summer and false in winter for 20 years. It is simply not possible to take the new DST true/false flag and negate it to call this method only in the case where there is a negative SAVE value (I've tried - the problem is that you don't know if it is negative SAVE if the instant you are given is in the summer). Given that it will be impossible to make the code work with negative offsets, the only solution is to change the parser to reverse negative offsets back to positive ones. This will continue to meet the expectation of the vast majority of users that DST means a more forward in summer. (Not doing this will just result in bug reports where users complain that isDaylightSavings() is returning true in winter). As such, I believe that negative SAVE values should be removed permanently from tzdb and explicitly banned. The timestamps can always be represented the other way around, and the meaning of the abbreviation wrt which is "standard" is not the concern of tzdb anyway (which should be focussed on telling the time). Stephen On 19 January 2018 at 08:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.)
There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time.
The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.
On 01/19/2018 03:16 AM, Stephen Colebourne wrote:
there is lots of underlying code in other parts of the JDK (which can't be changed as its been that way for 20 years) that takes a DST boolean flag:
TimeZone.getDisplayName(boolean daylight, int style, Locale locale) https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getDisplay...
This method has expected the daylight flag to be true in summer and false in winter for 20 years.
In what sense does the method "expect" DST to be true in Irish summer and false in Irish winter? That is, what exactly goes wrong if that expectation is not met? Can you illustrate the problem with a small Java application that breaks if Java treats Irish Standard Time as standard time? (A minor point of terminology: at bottom, this is an issue about negative DST offsets, not about whether DST is observed in summer or winter. For example, for America/Boa_Vista the daylight flag is true in winter and false in summer for timestamps through the year 2000, but I doubt whether any Java apps care because the DST offset was positive in Boa Vista during that period.)
It is simply not possible to take the new DST true/false flag and negate it to call this method only in the case where there is a negative SAVE value
I don't see why that would be needed. The DST boolean can continue to say whether DST is in effect, just as before.
Given that it will be impossible to make the code work with negative offsets, I don't see where the Java API disallows negative DST offsets. For example, in Oracle Java 9.0.4, TimeZone.getDSTSavings returns an 'int', and this allows for negative offsets.
So far, we've seen failures only in Java test suites, which aren't a major concern. What will be the effect on Java applications? That's the more important question.
On 01/19/2018 03:16 AM, Stephen Colebourne wrote:
this patch did not revert all of the changes! Instead it effectively disabled the negative SAVE value in the "Rule" section by not using it from the "Zone" section.
I installed the attached proposed patch on the off-chance that some software somewhere will break because of the unused Eire rules. This patch should be part of 2018c once it is released. We can re-add the Eire rules when we remove the workaround for the ICU and OpenJDK problems.
I think it's fine to roll back this cosmetic change - particularly if there's still ongoing discussion as to whether it is or is not going to be included in the end (about which I am ambivalent) - but if the change *is* coming, I don't think waiting a year to release the new version is the right thing to do. The problem is that, as we have found out with this release, even people with year-long lead times don't seem to bother testing against anything except the release version of the database. I think what is likely to happen is 2018c comes out reverting this change, all the alarms stop going off when 2018c is updated, and the common wisdom is "don't use 2018a or 2018b", then when 2019a comes out the same problem happens again. It seems to me like the right thing to do would be to cut a 2018c release, figure out whether negative SAVE is worth the hassle and if it's decided that negative SAVE values *are* valid, then a new release should be cut maybe 1 month afterwards that has the negative SAVE values. Broken compilers with a long release cycle should probably just create their own distribution channel for a patched version of zoneinfo that maintains their erroneous assumptions about the code until a fix is released. Another alternative might be to create a "testzone" file containing test zones that deliberately violate various assumptions that downstream consumers may have made but which are *not* intended to be stable features of the data, and could include a zone that contains negative SAVE. Then upstream the negative SAVE can be delayed a year in the Europe/Dublin zone and downstream consumers can skip testzone in production builds. I personally prefer the first approach - the tzdata should not be slowed down to the release cycle of the slowest consumer of the data. This change will have to permeate through a lot of software that *indirectly* uses these zonefiles (and it's not terribly reasonable to test against dev builds of all your direct *and indirect* dependencies), so waiting a year before it gets through the first-level consumers means this process could be drawn out interminably. Best, Paul On 01/19/2018 12:44 AM, Philip Paeps wrote:
On 2018-01-18 19:39:50 (-0500), Tom Lane wrote:
Zefram <zefram@fysh.org> writes:
There was indeed a significant chance of the negative SAVE value breaking alternate zic implementations, and now that that's turned out to be the case that's good cause to postpone this correction, or at least the expressing of it in this natural manner. The tzdb does have unusually high stability requirements. But that's not a reason to keep the database forever inaccurate.
I'm not sure that it's "inaccurate". The question is more about what is the meaning of tm_isdst = 1. It's clear from this discussion that an awful lot of code believes it means "local time is advanced now compared to what it is when tm_isdst = 0". Arguing that it should reflect a legalistic definition of DST, rather than an operational definition, is just an argument; it's not conclusive.
FWIW, I share the opinion that this change was misguided.
I'd go with "premature" rather than "misguided".
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Philip
Catching up on this thread, this one item jumped out at me: Philip Paeps <philip@trouble.is> wrote on Fri, 19 Jan 2018 at 06:44:15 +0100 in <20180119054415.GF75764@rincewind.trouble.is>:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
We need to be clear that in the world of timezone software, with complex downstream dependencies and embedded devices and mobile devices with weird update strategies that take data but not code, a year is *not* a long period of time. It's not long for tzdata, but it is far shorter for code. A year is a short period of time. It's not enough time for product life cycles, for deploying code changes reliably, etc. I'm not sure what the right amount of time is, but if we think a year is short, we are fooling ourselves. I also concur that there have been a lot of destabilizing changes in the tz database in recent years and that they seem to me like a not-very-good idea. Many of these changes would be fine if we had been starting from scratch and it was the first release, but we're not, and so they are not. (Relatively unimportantly, I particularly wonder at the effect of changes that adjust the historical rules of some zones from long ago, as we decide Shanks was wrong, etc. If anyone in such a zone had files in their filesystem with dates that far back, they would see weird churn and and odd changes relative to more recent timestamps, and I wonder at the wisdom of making those changes.) --jhawk@mit.edu John Hawkinson
On 1/20/18 11:08, John Hawkinson wrote:
I also concur that there have been a lot of destabilizing changes in the tz database in recent years and that they seem to me like a not-very-good idea. Many of these changes would be fine if we had been starting from scratch and it was the first release, but we're not, and so they are not.
(Relatively unimportantly, I particularly wonder at the effect of changes that adjust the historical rules of some zones from long ago, as we decide Shanks was wrong, etc. If anyone in such a zone had files in their filesystem with dates that far back, they would see weird churn and and odd changes relative to more recent timestamps, and I wonder at the wisdom of making those changes.)
--jhawk@mit.edu John Hawkinson
Again this suggests to me that we need to differentiate between the core timezone data - which should be as (historically) accurate as possible - and the data used by services which may well rate stability higher than accuracy. The second can easily be derived from the first either by creating modified copies or by the tools making adjustments. As for the churn in past data - it suggests to me that we should be storing version information along with the dates and ids. That's not going to help data in the past but we should be trying to improve matters moving forward
Michael Douglass wrote:
we should be storing version information along with the dates and ids. Starting with 2016g, releases have come with a file called 'version' that contains a version number. Starting with 2018a releases, this version number is also in the file 'tzdata.zi'. This version number can be used by downstream data parsers as needed; tzcode does not use it.
The development repository contains more-detailed information for all changes made to the published code or data since 1984.
On 1/20/18 20:46, Paul Eggert wrote:
Michael Douglass wrote:
we should be storing version information along with the dates and ids. Starting with 2016g, releases have come with a file called 'version' that contains a version number. Starting with 2018a releases, this version number is also in the file 'tzdata.zi'. This version number can be used by downstream data parsers as needed; tzcode does not use it.
The development repository contains more-detailed information for all changes made to the published code or data since 1984. Yes - by 'we' I meant consumers and users of the timezone data. However, it might be useful to have a timestamp associated with zone and rule data. The timestamp of any zone then becomes the latest of the associated timestamps.
John Hawkinson wrote:
in the world of timezone software, with complex downstream dependencies and embedded devices and mobile devices with weird update strategies that take data but not code, a year is *not* a long period of time. It's not long for tzdata, but it is far shorter for code.
As I understand it, the important problem with negative DST lies not in tzcode (it works just fine), nor with libraries that use the binary output of zic (so far, no problems have been reported for them, and this makes sense if you look at the format of the binary data), nor even with applications that use those libraries (so far, just one quite-minor and easily-fixed problem has been reported, and it was reported only because I looked carefully through perhaps the most tzcode-intensive application on the planet). No, the main problem with negative DST offsets appears to lie in other tzdata consumers, which assume that DST offsets must be positive. Until 2018a the zic man page did not document that negative DST offsets were allowed in zic input, and developers of some other software missed the possibility of negative DST offsets even though tzcode has supported them for decades. We've run into similar problems in the past with tzcode directly. That is, we've changed tzcode to extend the format of zic input, and then we've waited a while before using these extensions in tzdata. This wait gave downstream developers time to upgrade their zic implementations to add support for these extensions. Given that negative DST wasn't clearly documented until 2018a, I also suggest that we extend a sizable grace period to downstream code, as it will take some time for people to update that code and get updated versions into production. During that transition period, we can provide options so that downstream users can use the full data, or a bowdlerized version of the data that avoids negative DST but is otherwise as close to the original as is practical. This can all wait until after 2018c is announced.
I don't think that a compelling reason has been me for this change in the first place. No matter what the 'transition' period is, why do we need to do any of this? Why upset a huge number of older implementations? The reason has to be pretty darned important... {phone} On Sat, Jan 20, 2018, 17:51 Paul Eggert <eggert@cs.ucla.edu> wrote:
John Hawkinson wrote:
in the world of timezone software, with complex downstream dependencies and embedded devices and mobile devices with weird update strategies that take data but not code, a year is *not* a long period of time. It's not long for tzdata, but it is far shorter for code.
As I understand it, the important problem with negative DST lies not in tzcode (it works just fine), nor with libraries that use the binary output of zic (so far, no problems have been reported for them, and this makes sense if you look at the format of the binary data), nor even with applications that use those libraries (so far, just one quite-minor and easily-fixed problem has been reported, and it was reported only because I looked carefully through perhaps the most tzcode-intensive application on the planet).
No, the main problem with negative DST offsets appears to lie in other tzdata consumers, which assume that DST offsets must be positive. Until 2018a the zic man page did not document that negative DST offsets were allowed in zic input, and developers of some other software missed the possibility of negative DST offsets even though tzcode has supported them for decades.
We've run into similar problems in the past with tzcode directly. That is, we've changed tzcode to extend the format of zic input, and then we've waited a while before using these extensions in tzdata. This wait gave downstream developers time to upgrade their zic implementations to add support for these extensions.
Given that negative DST wasn't clearly documented until 2018a, I also suggest that we extend a sizable grace period to downstream code, as it will take some time for people to update that code and get updated versions into production. During that transition period, we can provide options so that downstream users can use the full data, or a bowdlerized version of the data that avoids negative DST but is otherwise as close to the original as is practical. This can all wait until after 2018c is announced.
FWIW, vzic (at least the fork that is in libical) handles the negative offset just fine, although having "winter" time show up in a "daylight" component looks odd: BEGIN:STANDARD TZNAME:IST TZOFFSETFROM:+0000 TZOFFSETTO:+0100 DTSTART:19810329T010000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT TZNAME:GMT TZOFFSETFROM:+0100 TZOFFSETTO:+0000 DTSTART:19961027T020000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:DAYLIGHT On 01/18/2018 03:32 PM, Stephen Colebourne wrote:
This also broke Java: https://bugs.openjdk.java.net/browse/JDK-8195595 and no doubt also breaks ThreTen-Backport and Joda-Time (I don't have time to test them right now).
As I and others have indicated before, this change should not have happened. The likelihood of it breaking something was always very high, and the alleged reality is that it expresses is a fact that is irrelevant to most users (and is disputed anyway). This was change for changes sake.
The real problem here is the incessant fiddling with the data. The vast majority of users just want small stable updates representing actual changes in time zones, not the continuous refactoring we've been subjected to in the last few years.
Stephen
On 18 January 2018 at 20:24, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
-- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd
ICU uses a heavily-modified version of zic. The problem is at runtime, if a negative DST offset is encountered. Negative DST offsets are considered illegal, and an error is returned.
On Jan 18, 2018, at 12:24 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
(Sorry, hit send by accident) ICU uses a heavily-modified version of zic. The problem is at runtime, if a negative DST offset is encountered. Negative DST offsets are considered illegal, and an error is returned. http://bugs.icu-project.org/trac/browser/trunk/icu4c/source/i18n/simpletz.cp... if(savingsDST<= 0) { status= U_ILLEGAL_ARGUMENT_ERROR; } So you would need an implementation that doesn’t have a negative DST offset. Debbie
On Jan 18, 2018, at 12:24 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
Well, I am not astonished to see problems elsewhere with negative dst offset. About ICU4J, I am not sure but assume that they parse the source files. And about Java/OpenJDK which parses the source files, too: There is at least one issue reported => https://bugs.openjdk.java.net/browse/JDK-8195595 After having looked at the official Java source code of a timezone-method for determining if there is daylight or winter time at a given instant, I also suspect that this is another problem (not yet tested): Java would start with v2018a to report Irish Summer Time (IST) in winter and GMT in summer when it comes to formatting the Irish zone Europe/Dublin. By the way, my lib Time4J which parses the tz-sources to compile a distribution would have crashed if I had not watched this mailing list and prepared for the Ireland case in 2018a. And the necessary compiler and tzdata changes were not so trivial because I had also to care about the winter/summer-format described before. Meno Am 18.01.2018 um 21:24 schrieb Paul Eggert:
On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error).
Could you give more details? Is the problem with code that reads tzdb source files, or with code that reads binary files produced by zic? How can I reproduce the problem from the ICU source code? Is there a publicly-available bug report about the problem? (I looked for one in <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.) That sort of thing.
I'm asking for these details because there may be a way to implement Irish standard time while avoiding the specific problem that the ICU code is running into.
Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.
If the problem is serious enough and cannot be worked around, we could back out the change in the next tzdb release and then re-add the change later, once things have settled down.
I'm concerned as to why this problem wasn't discovered until now. The change for Ireland has been in the development repository since December 7 and was circulated for comments, and the only specific problem reported for it was so trivial that it was not worth worrying about. If ICU depends in crucial ways on undocumented properties of tzdb, then ICU maintainers need to monitor this mailing list and/or run tests based on the development repository, and do that on a regular basis. Otherwise further problems like this will be inevitable.
Meno Hochschild <mhochschild@gmx.de> wrote: ... |By the way, my lib Time4J which parses the tz-sources to compile a |distribution would have crashed if I had not watched this mailing list |and prepared for the Ireland case in 2018a. And the necessary compiler |and tzdata changes were not so trivial because I had also to care about |the winter/summer-format described before. My Timezone::RuleDat also used an unsigned 16-bit for .savesec. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 01/18/2018 01:36 PM, Meno Hochschild wrote:
I also suspect that this is another problem (not yet tested): Java would start with v2018a to report Irish Summer Time (IST) in winter and GMT in summer when it comes to formatting the Irish zone Europe/Dublin.
Yes, it sounds quite plausible that Java/OpenJDK would somehow translate "IST" to "Irish Summer Time" in Europe/Dublin. This assumption has been incorrect for quite some time, as for many years tzdata's Europe/Dublin has used "IST" to stand for "Irish Standard Time" for some timestamps (notably, between 1968 and 1971). Unfortunately the tzdata format does not allow this assumption to be stated in the data; it's only in comments. If the Java/OpenJDK model does not allow the same abbreviation ("IST" in this case) to mean different things at different times in the same location, that would be a shortcoming in the model regardless of whether the Irish data moves to timestamps with negative DST offsets. Java/OpenJDK is a different project from tzcode, and it has always supported a superset-of-a-subset of what tzcode supports. For example, Java (at least, Oracle's version of Java) does not support POSIX-format TZ settings; on the other hand, Java supports long names like "Pacific Standard Time" that tzcode does not. With that in mind, it would be understandable if Java/OpenJDK decides not to support negative DST offsets; it would be just one more thing in the list of things that tzcode has but Java lacks. If that happens, it should be possible for Java-based readers of tzdata source files to automatically translate negative DST offsets into positive ones (switching abbreviations of course), as I think Stephen Colebourne suggested. It's also possible that all things considered it would be better if Java supported negative DST offsets -- but that's not our call to make. We can give the Java folks some time to prepare for this by backing out the Irish changes for now. We can bring the changes back in the not-too-distant future, and in the meantime the Java folks can test their fixes on 2018b.
Java/OpenJDK is a different project from tzcode, and it has always supported a superset-of-a-subset of what tzcode supports. For example, Java (at least, Oracle's version of Java) does not support POSIX-format TZ settings; on the other hand, Java supports long names like "Pacific Standard Time" that tzcode does not. With that in mind, it would be understandable if Java/OpenJDK decides not to support negative DST offsets; it would be just one more thing in the list of things that tzcode has but Java lacks. If that happens, it should be possible for Java-based readers of tzdata source files to automatically translate negative DST offsets into positive ones (switching abbreviations of course), as I think Stephen Colebourne suggested. It's also possible that all things considered it would be better if Java supported negative
DST offsets -- but that's not our call to make.
I'm maintaining time zone data in CLDR and implementation in ICU. In ICU implementation, supporting negative DST offset in a new version is not difficult at all (only a few line of changes). A bigger problem is that we currently distribute only time zone data (in ICU consumable format) for updating older ICU releases. There are many ICU consumers who want the latest time zone data, but do not want to change anything else. Releasing a code patch for every past versions is a hassle for us too. I think Java folks are in the same situation.
We can give the Java folks some time to prepare for this by backing out the Irish changes for now. We can bring the changes back in the not-too-distant future, and in the meantime the Java folks can test their fixes on 2018b.
Java also imports time zone display name data from CLDR (BTW, CLDR uses "Irish Standard Time" as the long name). CLDR project cannot easily swap names for standard time and daylight saving time, because we also have many data consumers in various different implementations. Such change will definitely break our downstream consumers. I guess CLDR would just stay with the current (GMT as standard time, IST as daylight saving time) forever. In ICU, because we don't want to break ICU tz data backward compatibility, I decided to modify 2018a Europe/Dublin to swap standard time and daylight saving time, so we don't need to change localized display name data in many languages at least for now. Even ICU code is ready to support negative DST offsets, we may continue to swap standard/daylight for Europe/Dublin. -Yoshito Umaoka (Unicode CLDR/ICU)
On 01/19/2018 12:31 PM, Yoshito Umaoka wrote:
Java also imports time zone display name data from CLDR (BTW, CLDR uses "Irish Standard Time" as the long name). CLDR project cannot easily swap names for standard time and daylight saving time, because we also have many data consumers in various different implementations.
Thanks for your detailed summary. This "Irish Standard Time" usage has been a problem for many years, long predating tzdb-2018a. This is because "IST" stands for "Irish Summer Time" in Europe/Dublin timestamps before 1968-10-27, and for "Irish Standard Time" thereafter. This problem of mislabeling old timestamps is independent of the recent Irish tzdb changes, and if it were fixed I imagine that it wouldn't be that hard to support the approach taken by 2018a and 2018b. I can certainly see, though, why one might prefer to continue doing things the old way, even if it's not quite correct.
On 08/12/17 06:38, Paul Eggert wrote:
On 12/05/2017 02:16 AM, Derick Rethans wrote:
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT". Thanks for pointing this out; I was unaware that Ireland observes negative daylight-saving time in winter, instead of positive daylight-saving time in summer. This arguably is clearer than the common practice in North America and Europe, where "standard time" is observed only in a relatively small fraction of the year. I installed the attached proposed patch to fix the commentary along the lines that you suggested, and to change tm_isdst as well. UT offsets and abbreviations are unaffected by this change.
I'm not sure that switching from positive daylight savings in summer to negative daylight savings in winter is a terribly good idea, as it will probably result in various software headaches. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
Date: Fri, 8 Dec 2017 11:52:15 +0000 From: Ian Abbott <abbotti@mev.co.uk> Message-ID: <6e202839-e18a-4f8f-88f9-99bd678fa571@mev.co.uk> | I'm not sure that switching from positive daylight savings in summer to | negative daylight savings in winter is a terribly good idea, as it will | probably result in various software headaches. The vast majority of software that thinks it understands time is broken, and ought to be given headaches. For this issue, the very name "daylight savings" is, and always has been, absurd (and negative daylight savings is worse) - there is, in many areas winter time, summer time (and sometimes others) - in other areas, there is just "the time". and standard time is which ever applies at a particular instant. kre
On 2017-12-08 13:13, Robert Elz wrote:
For this issue, the very name "daylight savings" is, and always has been, absurd (and negative daylight savings is worse) - ..........
Wait a moment -- negative savings, that's a loan. So we have daylight savings and loan times, finally! Michael Deckers. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 2017-12-08 14:53:57 (+0100), Michael Deckers via tz wrote:
On 2017-12-08 13:13, Robert Elz wrote:
For this issue, the very name "daylight savings" is, and always has been, absurd (and negative daylight savings is worse) - ..........
Wait a moment -- negative savings, that's a loan. So we have daylight savings and loan times, finally!
No no no. It's only a loan if you spend more than what you have. It's actually a daylight "spend". Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On Dec 8, 2017, at 6:52 AM, Ian Abbott <abbotti@mev.co.uk> wrote:
On 08/12/17 06:38, Paul Eggert wrote:
On 12/05/2017 02:16 AM, Derick Rethans wrote:
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT". Thanks for pointing this out; I was unaware that Ireland observes negative daylight-saving time in winter, instead of positive daylight-saving time in summer. This arguably is clearer than the common practice in North America and Europe, where "standard time" is observed only in a relatively small fraction of the year. I installed the attached proposed patch to fix the commentary along the lines that you suggested, and to change tm_isdst as well. UT offsets and abbreviations are unaffected by this change.
I'm not sure that switching from positive daylight savings in summer to negative daylight savings in winter is a terribly good idea, as it will probably result in various software headaches.
Yup, it will. Just updated my tz lib to deal with it. Howard
On 12/08/2017 03:52 AM, Ian Abbott wrote:
I'm not sure that switching from positive daylight savings in summer to negative daylight savings in winter is a terribly good idea, as it will probably result in various software headaches.
Yes, it does have its problems and perhaps I was a bit hasty. On the other hand, the Irish statute seems quite clear: Irish Standard Time == UTC +01 for decades and this can't be waved away as a temporary aberration. Also, any POSIX-conforming system must already deal with the situation, e.g.: TZ='IST-1GMT0,M10.5.0,M3.5.0/1' specifies Irish time since 1996 with negative DST in winter. So, although there will undoubtedly be some software headaches, these headaches can happen on POSIX-conforming platforms even if we left tzdb alone. I checked all the timestamp-using code that I normally deal with, and found one fairly-obscure bug uncovered by this change: the "holidays" function of GNU Emacs ignores the tm_isdst flag and so reports this years' transitions as follows: Sunday, March 26, 2017: Daylight Saving Time Begins 1:00am (GMT) Sunday, October 29, 2017: Daylight Saving Time Ends 2:00am (IST) where it should output this: Sunday, March 26, 2017: Daylight Saving Time Ends 1:00am (GMT) Sunday, October 29, 2017: Daylight Saving Time Begins 2:00am (IST) That is, the timestamps and abbreviations are correct, but the words "Begins" and "Ends" are misplaced. This bug can be demonstrated without the recently proposed tzdata patch, by setting TZ as shown above. I fixed it in Emacs by installing the following: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ff105b366c24779769487... If this is illustrative of the sorts of glitches people will encounter by the change, I think we'll be OK; it's not a big deal. If there's something more serious, though, we should probably revert it (though of course keep documentation about the situation).
This whole thread appears to have missed the fact that Ireland is in the EU, and thus the normal EU rules on time apply. https://ec.europa.eu/transport/themes/summertime_ga "Standard Time In parallel to the summertime arrangement in the European Union, the Member States apply three different time zones or standard times. The decision on the standard time is a national competence. The standard time is determined in relation to GMT (Greenwich Mean Time)." ... "Three Member States (Ireland, Portugal and United Kingdom) apply GMT" As such, this thread is essentially choosing between two ways of expressing the same thing - the EU way and the way it is expressed in Irish law. http://www.irishstatutebook.ie/eli/1968/act/23/enacted/en/print http://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print The EU define "standard" one way. Irish law defines it the other way. Since EU law takes precedence over national laws, I'd suggest the EU definition should be used, ie. tzdb should not change. Stephen AFAIK, these are all defined in terms of "standard" On 8 December 2017 at 06:38, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/05/2017 02:16 AM, Derick Rethans wrote:
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT".
Thanks for pointing this out; I was unaware that Ireland observes negative daylight-saving time in winter, instead of positive daylight-saving time in summer. This arguably is clearer than the common practice in North America and Europe, where "standard time" is observed only in a relatively small fraction of the year. I installed the attached proposed patch to fix the commentary along the lines that you suggested, and to change tm_isdst as well. UT offsets and abbreviations are unaffected by this change.
Since EU law takes precedence over national laws, I'd suggest the EU definition should be used, ie. tzdb should not change.
Your statement conflicts with the actual EU law you quoted, which says:
The decision on the standard time is a national competence.
Surely? Regards, Malcolm -----Original Message----- From: tz [mailto:tz-bounces@iana.org] On Behalf Of Stephen Colebourne Sent: Sunday, 10 December, 2017 08:45 To: Time zone mailing list <tz@iana.org> Subject: [External] Re: [tz] Irish Standard Time vs Irish Summer Time This whole thread appears to have missed the fact that Ireland is in the EU, and thus the normal EU rules on time apply. https://ec.europa.eu/transport/themes/summertime_ga "Standard Time In parallel to the summertime arrangement in the European Union, the Member States apply three different time zones or standard times. The decision on the standard time is a national competence. The standard time is determined in relation to GMT (Greenwich Mean Time)." ... "Three Member States (Ireland, Portugal and United Kingdom) apply GMT" As such, this thread is essentially choosing between two ways of expressing the same thing - the EU way and the way it is expressed in Irish law. http://www.irishstatutebook.ie/eli/1968/act/23/enacted/en/print http://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print The EU define "standard" one way. Irish law defines it the other way. Since EU law takes precedence over national laws, I'd suggest the EU definition should be used, ie. tzdb should not change. Stephen AFAIK, these are all defined in terms of "standard" On 8 December 2017 at 06:38, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/05/2017 02:16 AM, Derick Rethans wrote:
No, I meant "Irish Standard Time". Ireland is "odd" because their standard time is what the rest of the British Isles calls "Summer Time" (BST). So Ireland uses "Irish Standard Time" and "GMT".
Thanks for pointing this out; I was unaware that Ireland observes negative daylight-saving time in winter, instead of positive daylight-saving time in summer. This arguably is clearer than the common practice in North America and Europe, where "standard time" is observed only in a relatively small fraction of the year. I installed the attached proposed patch to fix the commentary along the lines that you suggested, and to change tm_isdst as well. UT offsets and abbreviations are unaffected by this change.
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement on https://www.sc.com/rcs/ and Regulatory Compliance Disclosures on http://www.sc.com/rcs/fm Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at https://www.sc.com/en/banking-services/market-disclaimer.html Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit https://www.sc.com/en/banking-services/dodd-frank-disclosures.html for important information with respect to derivative products.
On 11 December 2017 at 09:06, Wallace, Malcolm via tz <tz@iana.org> wrote:
Since EU law takes precedence over national laws, I'd suggest the EU definition should be used, ie. tzdb should not change.
Your statement conflicts with the actual EU law you quoted, which says:
The decision on the standard time is a national competence.
Nope, because in the context of the EU law, standard time = winter time. So the national competence of Ireland is to definine what the offset is in winter. Stephen
Stephen Colebourne said:
Since EU law takes precedence over national laws, I'd suggest the EU definition should be used, ie. tzdb should not change. Your statement conflicts with the actual EU law you quoted, which says: The decision on the standard time is a national competence.
Nope, because in the context of the EU law, standard time = winter time. So the national competence of Ireland is to definine what the offset is in winter.
But it only defines "summer-time period" for the purposes of the Directive - i.e. when the period starts and ends - but not for any other purpose. It does *NOT* name the time periods. So, provided that the dates don't conflict with the Directive (which they don't), Ireland is free to use the terms "standard time" and "winter time" if it wants. -- 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
Stephen Colebourne said:
This whole thread appears to have missed the fact that Ireland is in the EU, and thus the normal EU rules on time apply.
https://ec.europa.eu/transport/themes/summertime_ga
"Standard Time In parallel to the summertime arrangement in the European Union, the Member States apply three different time zones or standard times. The decision on the standard time is a national competence. The standard time is determined in relation to GMT (Greenwich Mean Time)." ... "Three Member States (Ireland, Portugal and United Kingdom) apply GMT"
That is not stating EU law. EU law does not require the existence of three zones (if Ireland wanted to make IST = GMT and use GMT-1 in the winter, nothing in EU law forbids them). Nor does it name those zones. All EU law requires is harmonization of the changeover dates. -- 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 2017-12-08 06:38, Paul Eggert proposed the change:
+ This change does not affect UT + offsets or abbreviations; it affects only whether timestamps are + considered to be standard time or daylight-saving time, as + expressed in the tm_isdst flag of C's struct tm type. + (Discrepancy noted by Derick Rethans.) This is wrong: the dst bit determines whether timestamps are considered to be daylight-saving time or not. The definition of the tm_isdst flag does not even mention standard time, and standard time is not an antonym to daylight-saving time.
In fact, any dictionary tells us that daylight-saving time is advanced, and not retarded, over the time used otherwise, and the case of Ireland shows us that standard time may agree with daylight-saving time. Michael Deckers.
Michael H Deckers via tz wrote:
The definition of the tm_isdst flag does not even mention standard time
True, but other parts of POSIX make it clear that when tm_isdst is zero, standard time is intended. See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... and look at the TZ environment variable: POSIX says that its first few letters correspond to standard time and that later letters correspond to daylight saving time. As I understand it, you're proposing that the current Irish rules be represented by something like POSIX TZ='GMT0IST-1,M3.5.0/1,M10.5.0/2', i.e., that we set tm_isdst=1 during IST in summer and that daylight saving time equals summer time in Ireland. But the POSIX TZ requirement is that tm_isdst must be zero during standard time, so if IST denotes standard time then current Irish rules should be represented by something like POSIX TZ='IST-1GMT0,M10.5.0/2,M3.5.0/1'.
any dictionary tells us that daylight-saving time is advanced, and not retarded, over the time used otherwise,
Although that's typical I doubt whether we can take it as an axiom, as POSIX clearly allows DST to be retarded. Also, multiple sources talk about having standard time in summer and daylight-saving time in winter. See: https://en.wikipedia.org/wiki/Winter_time_(clock_lag)
On 2017-12-10 22:16, Paul Eggert wrote:
Michael H Deckers via tz wrote:
The definition of the tm_isdst flag does not even mention standard time True, but other parts of POSIX make it clear that when tm_isdst is zero, standard time is intended. See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... and look at the TZ environment variable: POSIX says that its first few letters correspond to standard time and that later letters correspond to daylight saving time.
They actually say that the alternative time zone is in effect, such as for DST. So tm_isdst actually means the alternative non-standard time zone "tm_isalt" and not necessarily DST per se.
any dictionary tells us that daylight-saving time is advanced, and not retarded, over the time used otherwise Although that's typical I doubt whether we can take it as an axiom, as POSIX clearly allows DST to be retarded. Also, multiple sources talk about having standard time in summer and daylight-saving time in winter. See: https://en.wikipedia.org/wiki/Winter_time_(clock_lag)
That could be usefully cross-referenced to the relevant zones or rules. I can see headaches coming for testers and implementers who did not allow for those cases! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 2017-12-10 22:16, Paul Eggert wrote:
Michael H Deckers via tz wrote:
The definition of the tm_isdst flag does not even mention standard time True, but other parts of POSIX make it clear that when tm_isdst is zero, standard time is intended. See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... and look at the TZ environment variable: POSIX says that its first few letters correspond to standard time and that later letters correspond to daylight saving time.
The meaning of fields in a POSIX TZ string does not define the meaning of the tm_isdst member of struct tm, which is only a matter of the C standard; POSIX cannot modify that meaning (they can only add extensions). Michael Deckers.
On 12/12/17 15:16, Michael H Deckers via tz wrote:
On 2017-12-10 22:16, Paul Eggert wrote:
Michael H Deckers via tz wrote:
The definition of the tm_isdst flag does not even mention standard time True, but other parts of POSIX make it clear that when tm_isdst is zero, standard time is intended. See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
and look at the TZ environment variable: POSIX says that its first few letters correspond to standard time and that later letters correspond to daylight saving time.
The meaning of fields in a POSIX TZ string does not define the meaning of the tm_isdst member of struct tm, which is only a matter of the C standard; POSIX cannot modify that meaning (they can only add extensions).
Michael Deckers.
POSIX does define the meaning of the tm_isdst member (The Open Group Base Specifications Issue 7 says: "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available."). This seems to be slightly inconsistent with its description of the "dst" part of the TZ environment variable, which designates the alternative (such as Daylight Savings Time) timezone. To make it consistent, I think POSIX should describe tm_isdst as indicating whether the alternative (such as Daylight Savings Time) timezone is in effect, or not, or undetermined. The C standard does not define "standard time" at all. It does say that tm_isdst is set to 1 when "Daylight Saving Time" is in effect, but defines "Daylight Saving Time" as "a temporary change in the algorithm for determining local time." -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
Paul Eggert said:
Michael H Deckers via tz wrote:
The definition of the tm_isdst flag does not even mention standard time
True, but other parts of POSIX make it clear that when tm_isdst is zero, standard time is intended. See:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
and look at the TZ environment variable: POSIX says that its first few letters correspond to standard time and that later letters correspond to daylight saving time.
Actually, it says "the alternative timezone", with "Daylight Savings Time" being an *example*.
But the POSIX TZ requirement is that tm_isdst must be zero during standard time,
Right.
so if IST denotes standard time then current Irish rules should be represented by something like POSIX TZ='IST-1GMT0,M10.5.0/2,M3.5.0/1'.
Looks right.
any dictionary tells us that daylight-saving time is advanced, and not retarded, over the time used otherwise,
Dictionaries are descriptive, not prescriptive, in English.
Although that's typical I doubt whether we can take it as an axiom, as POSIX clearly allows DST to be retarded.
Specifically, the same definition of TZ allows any offset for the alternative timezone; one hour ahead of the standard zone is merely the default. If it could only be forwards of the standard zone, there would be wording saying so. -- 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
Michael H Deckers via tz said:
+ This change does not affect UT + offsets or abbreviations; it affects only whether timestamps are + considered to be standard time or daylight-saving time, as + expressed in the tm_isdst flag of C's struct tm type. + (Discrepancy noted by Derick Rethans.) This is wrong: the dst bit determines whether timestamps are considered to be daylight-saving time or not. The definition of the tm_isdst flag does not even mention standard time, and standard time is not an antonym to daylight-saving time.
True. Of course, since the EU doesn't have "Daylight Saving Time", the flag should be zero throughout the year in the EU. -- 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 2017-12-12 13:07, Clive D.W. Feather wrote about the dst bit:
Of course, since the EU doesn't have "Daylight Saving Time", the flag should be zero throughout the year in the EU.
Yes, I think this is a valid and clear interpretation. But it would be English-oriented because only the US, Canada, the Kiwis and a few others could enjoy the dst bit. A more international approach would allow translations, such as summer time (British) and yaz saati (Turkish). And to make it even more international, one could use a functional definition such as "a temporarily advanced time scale, so as to extend the daylit evening hours" (or something better). The problem I see with the search for translations of "daylight-saving time" and "standard time" is that we had to do it for an impracticable large number of languages in order to make the tzdb data language independent. Michael Deckers.
On 2017-12-04 00:45, Paul Eggert proposed a list of abbreviations:
+NST/NDT/NWT/NPT/NDDT Newfoundland, +NZMT/NZST New Zealand through 1945,
This seems to miss NST/NDT/NWT/NPT Nome There is also the question of whether Theory covers backzone or not. In the case that the lists should include backzone data, abbreviations such as ADMT, and AMT for Asmara must be mentioned; otherwise it should be mentioned that additional uses of abbreviations in backzone are not listed. Michael Deckers.
Michael H Deckers via tz wrote:
This seems to miss NST/NDT/NWT/NPT Nome
Thanks, fixed in the attached proposed patch.
There is also the question of whether Theory covers backzone or not.
backzone is for stuff that's outside the scope of tzdb, so I would say "not". I attempted to clarify this point in the attached patch.
participants (40)
-
Brian Inglis -
christos＠zoulas.com -
Clive D.W. Feather -
David Patte ₯ -
Deborah Goldsmith -
Derick Rethans -
Garrett Wollman -
Guy Harris -
Howard Hinnant -
Ian Abbott -
J Andrew Lipscomb -
John Hawkinson -
Jon Skeet -
Jonathan Lennox -
Joseph Myers -
Ken Murchison -
Lester Caine -
Mark Davis ☕️ -
Matthew Donadio -
Meno Hochschild -
Michael Deckers -
Michael Douglass -
Michael H Deckers
-
Paul Eggert -
Paul G -
Paul Goyette -
Paul.Koning＠dell.com -
Philip Paeps -
Random832 -
Robert Elz -
Russ Allbery -
Steffen Nurpmeso -
Stephen Colebourne -
Steve Allen -
Thomas M Steenholdt -
Tim Parenti -
Tom Lane -
Wallace, Malcolm -
Yoshito Umaoka -
Zefram