Re: [tz] draft of change summary for next tz release
And some of us prefer having at least one zone for each ISO 3166-1 country. Several of us understood the old theory file to require this. 1970 is an arbitrary computer geek cutoff point, with not much meaning to general time zone history.
<<On Tue, 17 Sep 2013 18:33:35 -0400, David Patte ⯠<dpatte@relativedata.com> said:
1970 is an arbitrary computer geek cutoff point, with not much meaning to general time zone history.
Yes, but it's the arbitrary cutoff point that this project has used from the very beginning. -GAWollman
David Patte ₯ <dpatte@relativedata.com> writes:
And some of us prefer having at least one zone for each ISO 3166-1 country. Several of us understood the old theory file to require this. 1970 is an arbitrary computer geek cutoff point, with not much meaning to general time zone history.
None of these proposed changes make the database any better or worse in this regard so far as I can tell. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
I am concerned about the change of Europe/Vaduz into a link to Europe/Zurich. There was a long discussion about how and when Swiss time was standardised, yet no-one (except myself) seemed concerned that Vaduz is not actually in Switzerland. No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland, and if it does, when that decision was made by the legislature. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Russ Allbery Sent: 18 September 2013 00:10 To: tz@iana.org Subject: Re: [tz] draft of change summary for next tz release David Patte ₯ <dpatte@relativedata.com> writes:
And some of us prefer having at least one zone for each ISO 3166-1 country. Several of us understood the old theory file to require this. 1970 is an arbitrary computer geek cutoff point, with not much meaning to general time zone history.
None of these proposed changes make the database any better or worse in this regard so far as I can tell. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> 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.
STILL battling with pigging windows computers ... up until 2AM last night and 1AM this morning ... now to get W7 to actually load VNC so I can log in :( Wallace, Malcolm wrote:
I am concerned about the change of Europe/Vaduz into a link to Europe/Zurich. There was a long discussion about how and when Swiss time was standardised, yet no-one (except myself) seemed concerned that Vaduz is not actually in Switzerland. No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland, and if it does, when that decision was made by the legislature.
Personally I share your concern, and *I* would like to see some mechanism in place so that even the current possible incorrect data was handled as part of the extended database we keep talking about. That two countries use the same set of rules is not a problem, but even just adding the link because they MAY have had the same change over date seems wrong. I think it is this inference that is creating confusion. But finding the real data is the key going forward, and we need local input for that? First silly thought ... arbitrary date for 'condensed' database is 1972 as defined by a time related event ... UTC started ... So the 'condensed' database is simply UTC related data. It's just a number ... but that seems better? I'm trying to help with the idea of the addition of 'thousands' of timezones, and in the end if there is evidence for thousands in the USA then they simply need documenting anyway! I'm glad that this corner of Europe is a little easier. It sounds as if small pockets of communities combined over a period of time? So my idea of an 'extended' file is still probably valid, but instead of a single entry showing the link to the 'condensed' timezones, there will be additional cross links within it to other location tags. My LMT *and* LMTZ data stays in 'extended' and only the 'condensed' data is kept separate. I think that what is confusing people is that some timezones have historic data that does not relate to the locations being linked to it? I've found additional data that pre-dates GMT and currently those timezones have their own id's but how do you later add id's if similar material is uncovered? Either all historic stuff is in 'extended' or it all goes into 'current'? Using the particular link being discussed Europe/Vaduz -> Europe/Zurich Have we not established more material pre 1972 for Europe/Zurich which probably does not apply to Europe/Vaduz? Not had time to digest all the material :( I would still like to tidy up 'backward' as well to actually contain dates that a particular alias was used from 'officially'. There must be a lot of archive material that uses them, and if one can cross check that a timezone was 'official' then it's a cross check on that material. This is more history that is being lost! -- 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
Alan Barrett wrote:
On Wed, 18 Sep 2013, Lester Caine wrote:
My LMT *and* LMTZ data stays in 'extended' and only the 'condensed' data is kept separate.
You often mention "LMTZ". What does that term mean?
It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone' Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones? -- 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 Wed, 18 Sep 2013, Lester Caine wrote:
You often mention "LMTZ". What does that term mean?
It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone'
What is an LMT based zone? Zones are geographical areas, whereas LMT is associated with points.
Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones?
Sorry, I am still too confused about your terminology to try answering that. --apb (Alan Barrett)
Alan Barrett wrote:
You often mention "LMTZ". What does that term mean?
It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone'
What is an LMT based zone? Zones are geographical areas, whereas LMT is associated with points.
Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones?
Sorry, I am still too confused about your terminology to try answering that.
Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is. and different locations have a different offset. Anything on the same longitude will be the same time. When people started standardising they agreed on a Local Mean Time that applied across a bigger area. Now while towns may be on the same longitude their time offset would be different depending on the other locations in their group? I'm probably wrong but I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention? So prior to that all time was 'mean time' and it just depended on which longitude was being used to set it. 1915 started messing things up with the first varying time rules? Up until 1915 all we need to know is how the 'offset' from LMT was set when groups of locations agreed on a standard ... which is my 'LMTZ' data. -- 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 2013-09-18 10:17, Lester Caine wrote:
Alan Barrett wrote:
You often mention "LMTZ". What does that term mean?
It was my attempt at separating the early LMT times everywhere, and the early standardisations to an LMT based 'zone'
What is an LMT based zone? Zones are geographical areas, whereas LMT is associated with points.
Naively I assumed that would be an easier transition than it obviously actually is? So we just move the switch-over point from 'location' based time to timezones?
Sorry, I am still too confused about your terminology to try answering that.
Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is. and different locations have a different offset. Anything on the same longitude will be the same time.
When people started standardising they agreed on a Local Mean Time that applied across a bigger area. Now while towns may be on the same longitude their time offset would be different depending on the other locations in their group? I'm probably wrong but I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention? So prior to that all time was 'mean time' and it just depended on which longitude was being used to set it. 1915 started messing things up with the first varying time rules?
Up until 1915 all we need to know is how the 'offset' from LMT was set when groups of locations agreed on a standard ... which is my 'LMTZ' data.
I think you may be saying that standard time really just follows LMT at some other location or longitude, and LMT for a location is set from that location's longitude; LMTZ documents pre-DST zones using an offset from some other arbitrary location's arbitrary longitude e.g. the local university observatory.
On 09/18/13 09:17, Lester Caine wrote:
Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is.
No, traditionally 'midday' was when the sun was highest, which corresponds to solar time. Local Mean Time is a modification of solar time -- it is solar time averaged out over the year, with equal-length 24-hour days. Many locations changed from solar time to mean time at some point during their histories, but no attempt is made to record these transitions in the tz database.
When people started standardising they agreed on a Local Mean Time that applied across a bigger area.
Yes, that happened in some regions (France and Switzerland are two examples, the Swiss with two mean-time time zones) but not all. For example, it did not happen in California, as far as I know.
I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention?
Yes, it was first implemented in the 20th century (invented in the 19th).
So prior to that all time was 'mean time'
No, a lot of it (if you go back in history) was solar time, which depends on latitude as well as longitude. Of course most people way back when didn't care about the difference between solar time and mean time; but there is a difference.
1915 started messing things up with the first varying time rules?
Yes (though it was actually 1916, not 1915). For more about solar time versus mean time, please see Wikipedia: http://en.wikipedia.org/wiki/Local_mean_time http://en.wikipedia.org/wiki/Solar_time
On Wed, 18 Sep 2013, Lester Caine wrote:
Alan Barrett wrote:
You often mention "LMTZ". What does that term mean? Hopefully we can agree that pre standardisation, people based their local time on 'midday' which is what what Local Mean Time is. and different locations have a different offset. Anything on the same longitude will be the same time.
OK so far, except for the difference between solar time (where clocks are synchronised to midday every day, and days are not all the same length because the elapsed time between one solar midday and the next varies from day to day throughout the year) and mean time (where clocks are synchronised to a notional "mean" midday, and days are all the same length).
When people started standardising they agreed on a Local Mean Time that applied across a bigger area.
I'd say that they agreed on a time that applied across a bigger area. That time no longer deserved the name "Local Mean Time" because, for most locations in the zone, it was no longer the mean time that applied to their location.
I'm probably wrong but I am fairly sure that 'summer-time' or 'daylight saving is a 20th century invention?
Yes, I think so.
So prior to that all time was 'mean time' and it just depended on which longitude was being used to set it. 1915 started messing things up with the first varying time rules?
Up until 1915 all we need to know is how the 'offset' from LMT was set when groups of locations agreed on a standard ... which is my 'LMTZ' data.
They didn't agree on an offset from LMT. They couldn't, because LMT is different for every line of longitude in the area covered by the zone. They agreed on a place whose local mean time would be used throughout the zone, or they agreed on an offset between their time and the time in some other place. Anyway, I think I am starting to get the picture. When you say "LMTZ" you mean something like "A standardised time that applies across a geographical zone of significant size." I think it's confusing for you to refer to this time using a phrase that includes the words "Local Mean Time". --apb (Alan Barrett)
On Sep 18, 2013, at 12:19 PM, Alan Barrett <apb@cequrux.com> wrote:
Anyway, I think I am starting to get the picture. When you say "LMTZ" you mean something like "A standardised time that applies across a geographical zone of significant size." I think it's confusing for you to refer to this time using a phrase that includes the words "Local Mean Time".
Yes. Standard time *happens* to be local time for some locations, but it's *not* local time for most of the locations to which it applies, and the locations for which it happens to be local time are less interesting than the resulting time offset (if you really *want* the longitude for those locations, you can calculate it from the time offset). Let's just call it "standard time" - or, if you want to distinguish between time that doesn't shift over time and time that does ("daylight savings time", "summer time", etc.), call it "standard time without daylight savings time" or "standard time without summer time" or "standard time without seasonal shifts" or....
Guy Harris wrote:
Anyway, I think I am starting to get the picture. When you say "LMTZ" you mean something like "A standardised time that applies across a geographical zone of significant size." I think it's confusing for you to refer to this time using a phrase that includes the words "Local Mean Time". Yes. Standard time*happens* to be local time for some locations, but it's*not* local time for most of the locations to which it applies, and the locations for which it happens to be local time are less interesting than the resulting time offset (if you really*want* the longitude for those locations, you can calculate it from the time offset).
Let's just call it "standard time" - or, if you want to distinguish between time that doesn't shift over time and time that does ("daylight savings time", "summer time", etc.), call it "standard time without daylight savings time" or "standard time without summer time" or "standard time without seasonal shifts" or....
I prefer Alan's simplification. Yes that is all I'm trying to get at. but the point is that it is simply an agreed time for a location which may change as a location uses one or other 'standard'? And that all this needs is a date and an offset. At some point in the future we may also need a 'clock' but I suspect that will not be so well documented? Lets keep the term 'timezone' for the more complex rules involving all the annual changes which is the only time 'rules' are required? Does that simplify the number of timezones problem? -- 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 Sep 18, 2013, at 2:48 PM, Lester Caine <lester@lsces.co.uk> wrote:
Yes that is all I'm trying to get at. but the point is that it is simply an agreed time for a location which may change as a location uses one or other 'standard'?
A given set of locations may well change what offset from GMT/UTC it uses; those are recorded in the Zone lines for the tzdb zone corresponding to that set of locations.
And that all this needs is a date and an offset.
A set of dates/times and offsets, to handle the changes.
At some point in the future we may also need a 'clock' but I suspect that will not be so well documented?
If by "need a 'clock' but I suspect that will not be so well documented" you mean that the changes occur at a particular time on a particular date, whether the particular time is well documented or not, Zone lines already handle that; see, for example, the Zone lines for America/New_York: Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58 -5:00 US E%sT 1920 -5:00 NYC E%sT 1942 -5:00 US E%sT 1946 -5:00 NYC E%sT 1967 -5:00 US E%sT which specify that the America/New_York tzdb zone switched from local time to Eastern Standard time, following standard US "seasonal time shift" rules (which didn't have seasonal time shifts until 1918) on 1883-11-18 12:03:58.
Lets keep the term 'timezone' for the more complex rules involving all the annual changes which is the only time 'rules' are required?
Unfortunately, at least in the US (and possibly other countries), the term "time zone" is used to refer to regions with a given base standard time; that form of time zone may include multiple subregions with *different* "seasonal time shift" rules. For example, the Mountain Standard Time zone includes Colorado: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Denver 1920 1921 - Mar lastSun 2:00 1:00 D Rule Denver 1920 only - Oct lastSun 2:00 0 S Rule Denver 1921 only - May 22 2:00 0 S Rule Denver 1965 1966 - Apr lastSun 2:00 1:00 D Rule Denver 1965 1966 - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Denver -6:59:56 - LMT 1883 Nov 18 12:00:04 -7:00 US M%sT 1920 -7:00 Denver M%sT 1942 -7:00 US M%sT 1946 -7:00 Denver M%sT 1967 -7:00 US M%sT and Arizona: Zone America/Phoenix -7:28:18 - LMT 1883 Nov 18 11:31:42 -7:00 US M%sT 1944 Jan 1 00:01 -7:00 - MST 1944 Apr 1 00:01 -7:00 US M%sT 1944 Oct 1 00:01 -7:00 - MST 1967 -7:00 US M%sT 1968 Mar 21 -7:00 - MST but, as that shows, Colorado currently largely follows the US "daylight savings time" rules and Arizona doesn't. So I prefer terms such as "tzdb zone" to refer to those things that have tzids. I'm not wedded to *that* term, but there should be *some* term other than "time zone" for that. The tzdb currently does not have a concept of "time zone" in the sense of a region with a specified base time offset; are you suggesting that it add one?
Does that simplify the number of timezones problem?
I don't think so. The "number of timezones" problem, if by that you mean the problem that recording the times that particular regions adopted standard time in the tzdb would, as claimed, require thousands of new tzids, would not be solved by terminology - you're going to require thousands of new tzids no matter what.
Guy Harris wrote:
At some point in the future we may also need a 'clock' but I suspect that will not be so well documented?
If by "need a 'clock' but I suspect that will not be so well documented" you mean that the changes occur at a particular time on a particular date, whether the particular time is well documented or not, Zone lines already handle that; see, for example, the Zone lines for America/New_York: Sorry - in my mind 'date' is a timestamp all the time - and 1830's is a date with a 10 year time span ... genealogical standard terminaology. By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;)
Lets keep the term 'timezone' for the more complex rules involving all the annual changes which is the only time 'rules' are required? Unfortunately, at least in the US (and possibly other countries), the term "time zone" is used to refer to regions with a given base standard time; that form of time zone may include multiple subregions with *different* "seasonal time shift" rules. For example, the Mountain Standard Time zone includes Colorado: So I prefer terms such as "tzdb zone" to refer to those things that have tzids. I'm not wedded to *that* term, but there should be *some* term other than "time zone" for that. The tzdb currently does not have a concept of "time zone" in the sense of a region with a specified base time offset; are you suggesting that it add one? I'm not sure I even understand the subtlety of that statement. All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one. I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset?
I'm just trying to lay down a framework that we can agree on so we can start to hang what information we do have onto the right structure. -- 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 Sep 19, 2013, at 1:10 AM, Lester Caine <lester@lsces.co.uk> wrote:
Guy Harris wrote:
At some point in the future we may also need a 'clock' but I suspect that will not be so well documented?
If by "need a 'clock' but I suspect that will not be so well documented" you mean that the changes occur at a particular time on a particular date, whether the particular time is well documented or not, Zone lines already handle that; see, for example, the Zone lines for America/New_York: Sorry - in my mind 'date' is a timestamp all the time - and 1830's is a date with a 10 year time span ... genealogical standard terminaology. By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;)
By "24 hour days" do you mean "24 hour clock", as in "one hour past noon is 13:00:00 (or 13h 00m 00s or...) rather than 1:00:00 PM", or do you mean something else? If you mean "24 hour clock", the tzdb does not keep track of representational issues such as "12 hour clock vs. 24 hour clock"; are you suggesting that it should perhaps do so?
All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one.
I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset?
I don't think there will be anything other than tzids, whether a given tzid refers to a region that doesn't have DST/summer time/whatever or to a region that does, so I see no point to saying the former refers to a "timegroup" and the latter refers to a "timezone". If we decide to have separate tzids for all sets of locations that adopted standard time at a given date/time, then the "historic" database may well have thousands of tzids, and there will be a way of winnowing the database down to merge tzids that didn't differ before whatever date is chosen as the reference point. I presume that if a bunch of tzids were merged into one as part of the winnowing process, one of those tzids would be kept and the others discarded in the winnowed version of the database.
Guy Harris wrote:
By 'clock' I meant the way time is calculated during the day ... when did '24 hour days' come in ;) By "24 hour days" do you mean "24 hour clock", as in "one hour past noon is 13:00:00 (or 13h 00m 00s or...) rather than 1:00:00 PM", or do you mean something else? If you mean "24 hour clock", the tzdb does not keep track of representational issues such as "12 hour clock vs. 24 hour clock"; are you suggesting that it should perhaps do so?
Why do you have to be so aggravating Guy ... This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database? History is important and recording the history of time needs a home ... even the changes to calendars fit into this history.
All I am trying to do is provide a way forward so we can document and include pre-1972 ( and I'm going to stick with that date as a reference ) so that the 'condensed' database can exist with the full historic one. I'm trying to be constructive here ... the historic database will have 10's of thousands of locations, but at some 'timestamp' they will all switch to Paul's reduced timezone set. I think that there will be another set of TIMEZONES which have complex rules between 1916 and 1972 and prior to that TIMEGROUPS with a simple time offset? I don't think there will be anything other than tzids, whether a given tzid refers to a region that doesn't have DST/summer time/whatever or to a region that does, so I see no point to saying the former refers to a "timegroup" and the latter refers to a "timezone". If we decide to have separate tzids for all sets of locations that adopted standard time at a given date/time, then the "historic" database may well have thousands of tzids, and there will be a way of winnowing the database down to merge tzids that didn't differ before whatever date is chosen as the reference point. I presume that if a bunch of tzids were merged into one as part of the winnowing process, one of those tzids would be kept and the others discarded in the winnowed version of the database.
Again this is just nit picking when I'm just trying to create a path forward. -- 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 Sep 19, 2013, at 2:45 AM, Lester Caine <lester@lsces.co.uk> wrote:
This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked.
"Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else?
This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database?
I very strongly believe that information about the history of the adoption of 24-hour clocks does not belong in the TZ database, as that's orthogonal to the adoption of standard time; it could be maintained in a completely separate database used by code that displays times with a 12-hour or 24-hour clock depending on, for each time displayed, the convention in effect at that time (rather than just using the current convention). That code could, for example, use localtime() (which might use the tzdb) to convert a time_t to year/month/day/hour/minute/second, and then choose whether to display the hour as is or to do if (hour > 12) display hour-12 with "PM" else display hour with "AM" based on that other database.
History is important and recording the history of time needs a home
I'm unconvinced that it needs a single home, or that, even if it does, the tzdb is the right home.
... even the changes to calendars fit into this history.
I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases.
Again this is just nit picking when I'm just trying to create a path forward.
I'm unconvinced that the path forward requires distinguishing between locations with complex rules and those that don't.
On 2013-09-19 13:23, Guy Harris wrote:
On Sep 19, 2013, at 2:45 AM, Lester Caine <lester@lsces.co.uk> wrote:
This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. "Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else? This is just part of the history that AT SOME POINT may want to be recorded. I know that some people could not care less and that perhaps is why we need to split completely from the TZ database? I very strongly believe that information about the history of the adoption of 24-hour clocks does not belong in the TZ database, as that's orthogonal to the adoption of standard time; it could be maintained in a completely separate database used by code that displays times with a 12-hour or 24-hour clock depending on, for each time displayed, the convention in effect at that time (rather than just using the current convention). That code could, for example, use localtime() (which might use the tzdb) to convert a time_t to year/month/day/hour/minute/second, and then choose whether to display the hour as is or to do if (hour > 12) display hour-12 with "PM" else display hour with "AM" based on that other database. History is important and recording the history of time needs a home I'm unconvinced that it needs a single home, or that, even if it does, the tzdb is the right home. ... even the changes to calendars fit into this history. I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases. Again this is just nit picking when I'm just trying to create a path forward. I'm unconvinced that the path forward requires distinguishing between locations with complex rules and those that don't.
Julian or other calendar dates used when/after standard time was adopted can be statically converted to Gregorian as neither the C date/time functions nor the tzdb handle any other calendar. Historical information preceding adoption of standard time might be better hosted with a time history project. I would imagine historians and astronomers have done some of this kind of work already.
Guy Harris wrote:
This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. "Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else? http://www.time-for-time.com/clocks.htm I was simply referring to the fact that how time was measured differs vastly ... and at some point it may be necessary to handle that, including your example.
... even the changes to calendars fit into this history. I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases. This is purely a mater of how far back the time related material is taken.
Again this is just nit picking when I'm just trying to create a path forward. I'm unconvinced that the path forward requires distinguishing between locations with complex rules and those that don't. This was PURELY an attempt to distinguish between Paul's very limited set of timezones, and the reality of historic records.
At the end of the day we still have no statement on how historic data will be handled. Personally I'm less interested in the straight jacket created by the 'c' code and more interested in the pure data as that is what I will work with myself, but I'm holding back until there is some plan in place to at least allow my pending patches can be handled ... I have a first cut on an import routine to SQL, and I have a fairly comprehensive table of county and smaller locations ready to integrate into the front end. The data has a place on it's own and does not need to be bundled with the code! -- 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 Sep 19, 2013, at 4:07 PM, Lester Caine <lester@lsces.co.uk> wrote:
Guy Harris wrote:
This was just a comment that once one moves back into 'pre-clock' time then there may well be information on how time is marked. "Marked" in what sense? You still haven't indicated whether you're referring to 12-hour vs. 24-hour clocks. Are you, or are you referring to something else? http://www.time-for-time.com/clocks.htm I was simply referring to the fact that how time was measured differs vastly ... and at some point it may be necessary to handle that, including your example.
It may be necessary for some software to handle that. I *REALLY* don't see most code that uses the tzdb, or that uses APIs that use the tzdb, needing to care about pre-standardized-time clocks except to indicate the date and time when standardized time was adopted, and don't think the tzdb needs to handle that. I think that belongs elsewhere. And, again, I also don't think my example needs to be handled by the tzdb. Does anybody else believe the tzdb should handle the history of 12-hour vs. 24-hour clocks or of pre-standardized-time timekeeping other than recording when standardized time was adopted? If not, I don't see any point in further discussion of those topics on the tz list.
... even the changes to calendars fit into this history. I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb, if a goal is to have APIs such as localtime() return correct year/month/day dates for times during the period after the adoption of standard time but before the adoption of the Gregorian calendar. I think other calendars should be handled by other databases.
This is purely a mater of how far back the time related material is taken.
I don't think the time related material in the tzdb should go back before the establishment of standard time, for some meaning of "establishment", whether it means "adoption of standard time nationwide as civil time" or something looser. And, at this point, as per Brian Inglis' comment, the tz code shouldn't worry about the Julian calendar, and should leave it up to other code to handle that, so that I think *all* other calendars should be handled by other databases. If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database). Does anybody else believe that the tzdb should handle non-Gregorian calendars? If not, I don't see any point in further discussion of that topic on the tz list.
At the end of the day we still have no statement on how historic data will be handled.
Do we have a statement as to which historic data, other than the date and time of the establishment of standard time, and changes to regions' standard time and "daylight savings"/"summer time"/whatever rules, should be handled by the tzdb *at all*? I think we need that first, so we don't spend any time and energy discussing how to handle items that we're not going to handle. I propose 1) *not* including information about non-Gregorian calendars; 2) *not* including information about whether time is presented with a 12-hour or 24-hour clock; 3) for time prior to the establishment of standardized time, including *only* information about the date and time of its establishment; and personally like Alan Barrett's statement: In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data. Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users. so that the tzdb can have historical data about standardized time *but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits.
On 2013-09-20 00:42, Guy Harris wrote:
I *REALLY* don't see most code that uses the tzdb, or that uses APIs that use the tzdb, needing to care about pre-standardized-time clocks except to indicate the date and time when standardized time was adopted, and don't think the tzdb needs to handle that. I think that belongs elsewhere.
Pre-standardized time is a fairly murky place. For example, pre-standardized Japanese time used 12 hours for night-time and 12 hours for day-time, with the lengths of each set of hours varying through the seasons. There were adjustable mechanical clocks that worked on this system. I hope no one would argue that this sort of thing belongs in the tzdb. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Guy Harris said:
Does anybody else believe the tzdb should handle the history of 12-hour vs. 24-hour clocks or of pre-standardized-time timekeeping other than recording when standardized time was adopted? If not, I don't see any point in further discussion of those topics on the tz list.
On the contrary, I don't even see how it's possible. There's no UK legislation that I'm aware of on the topic. I know that British Rail, Southend-on-Sea Corporation Transport, and Midland Red Bus all changed from 12-hour to 24-hour clocks in their published timetables in different years. Since there were scores if not hundreds of other transport companies in England alone, that's a huge amount of data that will never be found. And if one shop puts "open 9 to 6" on its sign while the one next door puts "Hours: 0800 to 1730", do we need to keep a record of that? The idea of itself is ridiculous.
I don't think changes to calendars before the adoption of standard time (as was the case for the adoption of the Gregorian calendar in Western countries) belong in the tzdb. *Perhaps* the changes from the Julian to the Gregorian calendar *after* the adoption of standard time belong in the tzdb, if there are any, should be recorded in the tzdb,
What about the adoption of other calendars? Didn't Sri Lanka spend some time on some other calendar? No, I don't believe this belongs in tzdb. It's interesting information, but that is *NOT* where it belongs.
I don't think the time related material in the tzdb should go back before the establishment of standard time, for some meaning of "establishment", whether it means "adoption of standard time nationwide as civil time" or something looser.
Agreed. And it should be further limited to information about the mapping from local standard time to UT (in the loose sense).
If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).
Seconded.
In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data. Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users.
so that the tzdb can have historical data about standardized time *but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits.
I think this is a good objective. -- 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
Clive D.W. Feather wrote:
If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database). Seconded.
From which the data for TZ should be extracted ... if that is the way forward. So we are all working with the same set of data.
In the long term, think that the tz project should attempt to provide as much high-quality data as is reasonably feasible, and that users of the tz data should have the ability to "winnow" and install only a subset of the data. Here, users of the tz data includes OS vendors, appliance vendors, other software projects, software packagers, system administrators, and end users.
so that the tzdb can have historical data about standardized time*but* should offer tools to allow users, in his sense, to discard historical data if it imposes what those users deem significant costs in excess of what they deem the benefits. I think this is a good objective.
Just to reiterate here why *I* found a problem. The PHP timezone tools return the daylight saving settings for the 2nd world war period, and there were some discrepancies that needed explaining. At that time I had no idea that TZ was NOT providing the right data pre-1970 but I can now see that simply by a fluke I was getting the necessary material. If distributions are now going to be including or excluding this information at leisure then we need some big flags saying if the returned information is correct or not. i.e. if winnowing results in different pre-1970 data then there is a big potential hole! THIS is why we need to understand just what is being proposed and what the results will be. That some of the current material is suspect is a red herring ... providing consistent auditable material would create a problem if winnowing then hides that data? Some users get one answer some another ... -- 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 20 September 2013 11:28, Lester Caine <lester@lsces.co.uk> wrote:
Clive D.W. Feather wrote:
If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).
Seconded. From which the data for TZ should be extracted ... if that is the way forward. So we are all working with the same set of data.
I suspect your desire to have all global historical data here at tzdb puts you in the minority. It is easy for you, and those who want to join you, to create an alternate repository, suck in the tzdb data and enhance it. The most likely approach is that you'd use tzdb data after 1970 and your own data before. For example, the vast majority of the 9 million Java developers will not want or expect additional IDs or additional historic data. By contrast, they will want and expect reasonable historic data for those IDs that do exist currently (and for that data to be enhanced over time, not degraded). Working elsewhere will give you a lot more freedom and avoid long discussions here, particularly as history tends to be subjective. This list should really be about current/future changes to tzdb, and occasional historic fixes to the current IDs. Stephen
Stephen Colebourne wrote:
On 20 September 2013 11:28, Lester Caine <lester@lsces.co.uk> wrote:
Clive D.W. Feather wrote:
If somebody wants to establish a Big Database of all changes in time and date reckoning, not just establishment of standard time and rules for changes from standard time, I have no problem with them doing so; I just don't think the tzdb should be that database, even if whoever establishes that database chooses to use the tzdb as part of their database (thus becoming a user of the database).
Seconded. From which the data for TZ should be extracted ... if that is the way forward. So we are all working with the same set of data.
I suspect your desire to have all global historical data here at tzdb puts you in the minority. It is easy for you, and those who want to join you, to create an alternate repository, suck in the tzdb data and enhance it. The most likely approach is that you'd use tzdb data after 1970 and your own data before.
For example, the vast majority of the 9 million Java developers will not want or expect additional IDs or additional historic data. By contrast, they will want and expect reasonable historic data for those IDs that do exist currently (and for that data to be enhanced over time, not degraded).
BUT ... If the location they are interested in diverges from the 'picked' timezone rules historically then they are actually getting the wrong information! I'd almost argue that NO historic data is better than a SINGLE subset arbitrarily selected? Currently there is no mechanism to tell you that the historic data may not actually apply at all?
Working elsewhere will give you a lot more freedom and avoid long discussions here, particularly as history tends to be subjective. This list should really be about current/future changes to tzdb, and occasional historic fixes to the current IDs.
-- 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:
I'd almost argue that NO historic data is better than a SINGLE subset arbitrarily selected? Currently there is no mechanism to tell you that the historic data may not actually apply at all?
These are both valid points. It's certainly easy to remove data before 1970 automatically, and some platforms do that now (QNX, for example), so the first option is already there and some platforms already take it. As for the second, we could add a comment to each zone specifying the earliest time stamp such that the zone is known to be valid for all locations in its region after that time. The default would be 1970, which means the tz database trivially conforms to this pattern now. I see two problems with this idea, though. First, it needs to be integrated with winnowing, and it's not yet clear how that would work. Second, and more important, except for Europe/London and perhaps a handful of other places, we wouldn't know what value to put into the comment, other than the default "1970". This seems a fairly serious objection.
Paul Eggert wrote:
Lester Caine wrote:
I'd almost argue that NO historic data is better than a SINGLE subset arbitrarily selected? Currently there is no mechanism to tell you that the historic data may not actually apply at all?
These are both valid points. It's certainly easy to remove data before 1970 automatically, and some platforms do that now (QNX, for example), so the first option is already there and some platforms already take it.
As for the second, we could add a comment to each zone specifying the earliest time stamp such that the zone is known to be valid for all locations in its region after that time. The default would be 1970, which means the tz database trivially conforms to this pattern now.
I see two problems with this idea, though. First, it needs to be integrated with winnowing, and it's not yet clear how that would work. Second, and more important, except for Europe/London and perhaps a handful of other places, we wouldn't know what value to put into the comment, other than the default "1970". This seems a fairly serious objection.
I think we have reached the point where it's clear that TZ is never going to support anything before 1970 with any reliability. winnowing is a pointless exercise unless you are prepared to add new data later. So the only SAFE way to distribute a sub-set of TZ data is not to link it to past history that it is not 100% related to. The only problem remaining is how to allow a correct historic record to be used with the restricted TZ data. -- 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 Fri, 20 Sep 2013, Lester Caine wrote:
Subject: Re: [tz] What is LMTZ?
Please change the Subject when you change the topic.
I think we have reached the point where it's clear that TZ is never going to support anything before 1970 with any reliability.
That's not at all clear to me, at least for values of "reliable" that approximate the best information that volunteers are able to find and contribute. I thought that we had been talking about ways to allow the tz project to add much more pre-1970 data without adversely affecting those who don't want the run time overhead of the additional data, and that winnowing support would be one of the first steps towards that future.
winnowing is a pointless exercise unless you are prepared to add new data later.
Well, yes. The reason we have been talking about winnowing is that it will allow new data to be added later
So the only SAFE way to distribute a sub-set of TZ data is not to link it to past history that it is not 100% related to. The only problem remaining is how to allow a correct historic record to be used with the restricted TZ data.
I can't parse that, but I suspect that it's a conclusion based on a premise that I don't accept. --apb (Alan Barrett)
Alan Barrett wrote:
So the only SAFE way to distribute a sub-set of TZ data is not to link it to past history that it is not 100% related to. The only problem remaining is how to allow a correct historic record to be used with the restricted TZ data.
I can't parse that, but I suspect that it's a conclusion based on a premise that I don't accept.
If the 'stock' distribution of TZ provides history for only ONE of the branches that end in a current timezone 'name' then for all other branches it is simply wrong? How do you know which 'timezone' the history actually belongs to and more important, how do you get the correct history? This is the current sticking point as I see it at the moment. It only makes sense to distribute data in the 'stock' distribution back as far as 1970 and return 'not supported' for previous dates since there is no simple way to identify what is valid prior to 1970 for a particular location? I'm in the lucky position that I can ensure that europe/isleofman and the other UK zones have valid historic data, but once I move to europe during the 20th century the results returned by TZ are more likely simply to be wrong? Therefore it does not make sense to return anything prior to 1970? -- 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 Sep 18, 2013, at 1:06 AM, Lester Caine <lester@lsces.co.uk> wrote:
I'm trying to help with the idea of the addition of 'thousands' of timezones, and in the end if there is evidence for thousands in the USA then they simply need documenting anyway!
Perhaps they do, but whether that document needs to take the form of thousands of extra tzids is another matter. If they do, we should definitely give packagers of the tzdb, such as OS vendors, the option of *not* providing those thousands of extra tzids.
I would still like to tidy up 'backward' as well to actually contain dates that a particular alias was used from 'officially'.
As far as I'm concerned, "backward" should contain only links provided for backwards-compatibility reasons when a tzid name change occurred, e.g. Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Regina Canada/East-Saskatchewan Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific and, I think: Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey which are, I think, backwards-compatibility links introduced with the naming convention change. The only historical information associated with them relates to the history of the tzdb *itself*, and that's not of any use to people using the tzdb. There are also backwards-compatibility links introduced due to city name changes, e.g. not using "foreigner's" names for the city, e.g. Link Africa/Asmara Africa/Asmera Link Asia/Kolkata Asia/Calcutta Link Asia/Chongqing Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. Some links in "backwards" should perhaps be moved to other files. (The politically-sensitive links might fall into that category.)
Guy Harris wrote:
The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. The date it was first used is important as well ... both of which are just pulled from the release history.
-- 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 Sep 18, 2013, at 2:11 AM, Lester Caine <lester@lsces.co.uk> wrote:
Guy Harris wrote:
The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. The date it was first used is important as well ... both of which are just pulled from the release history.
What is "it", and what does "used" mean here?
Guy Harris wrote:
Guy Harris wrote:
The only historical information associated with them is the date when the old names were deprecated, which has nothing to do with the history of time zones. The date it was first used is important as well ... both of which are just pulled from the release history. What is "it", and what does "used" mean here?
What I mean is that the old names where in official use for a period of time and those names are used in material created during that time, so the period that they were valid for is important information. I would go as far as to say that the legacy material would have been written with reference to the historic returns from the TZ database but that is a separate problem, and the correct version of TZ can easily be accessed if required. -- 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 Sep 18, 2013, at 9:45 AM, Lester Caine <lester@lsces.co.uk> wrote:
What I mean is that the old names where in official use for a period of time and those names are used in material created during that time, so the period that they were valid for is important information.
What do you mean by "valid"? Unless some packager of the tzdb drops the "backward" file, those names are still "valid" in the sense that, for example, I can do TZ=US/Eastern date or TZ=America/New_York date and get the same answer (and I just *did* that on my OS X Mountain Lion system - Apple didn't drop the "backward" file - so the old names are *still* valid on my Mac, at least).
<<On Wed, 18 Sep 2013 09:52:19 -0700, Guy Harris <guy@alum.mit.edu> said:
What do you mean by "valid"? Unless some packager of the tzdb drops the "backward" file,
FreeBSD stopped using the "backward" file more than a decade ago, as the links it contained were considered (by me) to be more confusing than beneficial. -GAWollman
Lester Caine wrote:
I'm trying to help with the idea of the addition of 'thousands' of timezones, and in the end if there is evidence for thousands in the USA
Not just in the US. There would be thousands in the rest of the world too.
It sounds as if small pockets of communities combined over a period of time
That's a problem, but it's not the only problem. Communities also changed their minds about the time. Sometimes this was due to a war (the conquering army would keep its capital's time), sometimes other political events. I wouldn't be surprised if (say) France would need even more zones than the US, due to the wars fought there. Shanks lists fewer zones for France than for Indiana, but I suspect that's merely because Shanks lived near Indiana and could better research for Indiana. I do like the idea of having an 'extended' file, for zones that are not likely to be of general interest. Right now, though, we're just trying to get the next release out.
Wallace, Malcolm wrote:
No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland
Actually I made the attempt, and came up empty. And it wasn't a casual attempt: I scoured the literature, both online and in paper, in both English and German, in the best research library in southern California. Of course I may have missed something, and the National Library of Liechtenstein would probably be a better library for this; but I did try. Alois Treindl wrote:
Vaduz (Liechtenstein) is a different country, with a different timezone history: no DST in 1941 and 1942.
I'm sorry, but there is no real evidence to support this claim, and I doubt that it's true. Shanks doesn't count as evidence, as he just makes things up. The Swiss astrology books don't count either, as they just make things up too -- my recent research proved them to be inventions even for *Switzerland*, so why should we pay attention to them for a neighboring country? Perhaps in the future someone will report good evidence for Liechtenstein. If that happens we can put a Zone entry for Vaduz into the database instead of merely having a Link. In the meantime, "We guess it's like Switzerland" is better than what was in the tz database before. (I suspect that "it's like Switzerland" is all that the astrologers guessed too, it's just that they were sloppier about it.) It's not just Liechtenstein. Similar issues afflict several other places in the tz database, some fixed already in 2013d, some fixed by the proposed changes, and others still awaiting work. I'm not talking merely about entries that are poorly sourced. I'm talking about entries that (given what we know now) are likely wrong.
On 18.09.13 16:58, Paul Eggert wrote:
Wallace, Malcolm wrote:
No attempt was made to show whether Liechtenstein follows the timezone rules for neighbouring Switzerland
Actually I made the attempt, and came up empty. And it wasn't a casual attempt: I scoured the literature, both online and in paper, in both English and German, in the best research library in southern California. Of course I may have missed something, and the National Library of Liechtenstein would probably be a better library for this; but I did try.
Alois Treindl wrote:
Vaduz (Liechtenstein) is a different country, with a different timezone history: no DST in 1941 and 1942.
I'm sorry, but there is no real evidence to support this claim, and I doubt that it's true. Shanks doesn't count as evidence, as he just makes things up. The Swiss astrology books don't count either, as they just make things up too -- my recent research proved them to be inventions even for *Switzerland*, so why should we pay attention to them for a neighboring country?
OK, I can confirm in this case that your intuition was right, and mine was wrong. You can link Europe/Vaduz to Europe/Zurich I found this source: http://www.eliechtensteinensia.li/LIJ/1978/1938-1978/1941.pdf which confirms on page 6 that Liechtenstein followed Switzerland in 1941 and 1942 I attach a screen copy, and translate only the last two paragraphs: ..during second world war, in the years 1941 and 1942, Liechtenstein introduced daylight saving time, adapting to Switzerland. From 1943 on central European time was in force throughout the year. From a report of the duke's government to the high council, regarding the introduction of a time law, of 31 May 1977.
Alois Treindl <alois@astro.ch> writes:
OK, I can confirm in this case that your intuition was right, and mine was wrong. You can link Europe/Vaduz to Europe/Zurich
I found this source: http://www.eliechtensteinensia.li/LIJ/1978/1938-1978/1941.pdf which confirms on page 6 that Liechtenstein followed Switzerland in 1941 and 1942
Thank you *very much* for doing this research. This is great: it lets us work from confirmed data instead of having to make guesses, and that will make the database better for every use case in the long run. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery wrote:
Thank you *very much* for doing this research.
Likewise! I very much appreciate good research like that. I know how much time and energy it can take; thanks. I plan to add the following to the release announcement: (Thanks to Alois Treindl for confirming that the old Europe/Vaduz zone was wrong and the new link is better for WWII-era times.) and have pushed the following patch, which affects only commentary.
From b8e081b8bae00f6939103b15657591af5856ddce Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Wed, 18 Sep 2013 10:39:29 -0700 Subject: [PATCH] * europe (Europe/Vaduz): Add confirming commentary from Alois Treindl.
--- europe | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/europe b/europe index 9cfe80f..a7b1676 100644 --- a/europe +++ b/europe @@ -1564,12 +1564,23 @@ Zone Europe/Riga 1:36:24 - LMT 1880 2:00 EU EE%sT # Liechtenstein + # From Paul Eggert (2013-09-09): # Shanks & Pottenger say Vaduz is like Zurich. -# Given the close ties between Liechtenstein and Switzerland during WWII, -# assume our circa-1941 corrections to Zurich apply also to Vaduz. + +# From Alois Treindl (2013-09-18): +# http://www.eliechtensteinensia.li/LIJ/1978/1938-1978/1941.pdf +# ... confirms on p. 6 that Liechtenstein followed Switzerland in 1941 and 1942. +# I ... translate only the last two paragraphs: +# ... during second world war, in the years 1941 and 1942, Liechtenstein +# introduced daylight saving time, adapting to Switzerland. From 1943 on +# central European time was in force throughout the year. +# From a report of the duke's government to the high council, +# regarding the introduction of a time law, of 31 May 1977. + Link Europe/Zurich Europe/Vaduz + # Lithuania # From Paul Eggert (1996-11-22): -- 1.8.3.1
participants (13)
-
Alan Barrett -
Alois Treindl -
Brian Inglis -
Clive D.W. Feather -
David Patte ₯ -
Garrett Wollman -
Guy Harris -
Ian Abbott -
Lester Caine -
Paul Eggert -
Russ Allbery -
Stephen Colebourne -
Wallace, Malcolm