March 2005 - tz - lists.iana.org

FW: Time zone: the next generation
by Olson, Arthur David (NIH/NCI) March 10, 2005

March 10, 2005

Since sending this message, Alois has joined the time zone mailing list. --ado -----Original Message----- From: Alois Treindl [mailto:alois@astro.ch] Sent: Thursday, March 10, 2005 5:54 AM To: Olson, Arthur David (NIH/NCI) Cc: Tz (tz(a)elsie.nci.nih.gov) Subject: Re: Time zone: the next generation On Thu, 3 Mar 2005, Olson, Arthur David (NIH/NCI) wrote: > QUESTIONS > > * Do we handle Julian/Gregorian transitions? Yes, but with an override feature in the API. One of the problems is that many history texts contain converted calendar dates. For the consistency of a particular history book, biography etc, authors have a tendency to convert all calendar data contained in them into one system, even if at the given date and location a different calendar might have applied. If a related calendar/timezone database makes strict assumptions about which calendar applied for a given date, then new problems are introduced. > * Do we allow control of skipping the year zero? Both styles of year counting have a name. The one with year zero is called 'astronomical year counting style' and it indicates years BC with negative year numbers. The one without year zero is called 'historical year counting style' and it indicates years BC with the suffix BC or BCE or something similar, but never with a plus/minus sign. I think the documentation should be clear, but the API needs only to support one style. > * Do we handle pegging of far-past and far-future times? Aside from calendar system changes, no time zone data are known for dates before the 1800s. There is an issue whether true solar time or mean solar time was used for the recording of a particular historical event. But I do not see how tzdata should be able to answer this question. E.g. when J.W.Goethe mentions in one of his works that he was born at noon on 28 August 1749 (greg. calendar) in Frankfurt: Does he mean true solar time (as indicated by a sun dial) or mean solar time (as measured by an astronomical clock in an observatory)? tzdata cannot know this, and should not claim that it knows. There was no clear transition between true solar time and mean solar time reckoning, before the formal introduction of timezone standards in the 19th century. Alois Treindl

1 0

Who ist the maintainer of tzdata?
by Alois Treindl March 10, 2005

March 10, 2005

I have a project to expand tzdata. Summarizing shortly, the rough idea is to - add boundary descriptions to each area with a different timezone history so that with given coordinates it can automatically be determined to which timezone history 'table' a given location belongs. I am aware that many non-trivial issues of geo-information processing arise with such a goal. - add more details for the complicated timezone history of some countries, e.g. Canada, where other sources have identified more than 250 regions with different timezone history, whereas current tzdata has only 15 regions. I am aware that this is a large project which will require resources measured in man-years. I may be in a position to contribute/sponsor such resources. I would like to communicate with the current maintainers of tzdata about these ideas, and about the best approach for such an expansion. My motivation background is the field of serious astrology, where reliable timezone history information is an essential requirement. tzdata is doing an excellent job to provide reliable information for current timzones, but it lacks sadly (and understandably, given the complexity of the problem) in historical detail. Alois Treindl

1 0

RE: Time zone: the next generation (future transitions)
by Olson, Arthur David (NIH/NCI) March 8, 2005

March 8, 2005

The Gregorian calendar cycles every 400 years: January 1 fell on a [Saturday] in 2000, and will do so again in 2400. In a traditional-zic approach, we could store 400 (or more) years worth of future transitions; stuff beyond that could be handled at run time. For example, a localtime call would, for far future times: cast out 400 years worth of seconds at a time to get to the near future (remembering how many years worth of seconds had been cast out); convert the resulting time_t value; and add the cast-off number of years to the resulting time_t value. We'd of course need to check at run time to verify that this was the right approach. --ado

1 0

Olson database name ambiguity
by Tom Yandell March 7, 2005

March 7, 2005

Hi Apologies for cross posting this. I think that this is a problem in the data in the Olson database, but as it is a binary format it is difficult to verify this. I have come across this problem using the DateTime perl module (version 0.28) whose data is generated from the Olson database. The problem that I am experiencing is that the short name for timezones for 'Europe/London' up until 1996 were either 'GMT' or 'BST' (depending if daylight saving changes were in effect). From 1996 the name for the timezone is the rather less precise 'GMT/BST' regardless of whether daylight saving changes are in effect or not. I have attached a script that demonstrates this, and its output. Regards, Tom

2 1

Re: FW: Time zone: the next generation
by kennykb＠crd.ge.com March 4, 2005

March 4, 2005

Clive Feather posts some interesting historical observations about the calendar, which I suppressed from my original posting because I thought that they'd drown the readers in irrelevant detail -- a one-line summary, in my arrogant opinion, is "we don't want to go there." -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

FW: Time zone: the next generation
by Olson, Arthur David (NIH/NCI) March 4, 2005

March 4, 2005

Kevin Kenny is on the time zone mailing list, but at a different address than that shown below. --ado -----Original Message----- From: kennykb(a)crd.ge.com [mailto:kennykb@crd.ge.com] Sent: Thursday, March 03, 2005 3:22 PM To: Tz (tz(a)elsie.nci.nih.gov) Subject: Re: Time zone: the next generation I've done a good bit of similar code for the Tcl programming language (see http://www.tcl.tk/cgi-bin/tct/tip/173 for details). The implementation there can handle the proleptic Julian calendar, with a defined change date. There are a number of caveats worth mentioning: - Prior to the Julian conversion, different locales had different rules for when the number of the year changed. In and before 1752 in Great Britain, for instance, the number of the year changed on 25 March; 1-24 March belonged to the previous year! With the adoption of the Gregorian calendar, the change was universally 1 January. (For this reason, you'll sometimes see eighteenth-century dates as O.S. ("Old Style") or N.S. ("New Style") when the year would otherwise be ambiguous. I decided for Tcl not to bother with any kind of localized rule for year numbering in those circumstances; it was too much of a mess. - As you correctly observe, leap years were observed irregularly in Rome in Republican and early Imperial times. In fact, they were so irregularly observed that it was occasionally necessary to intercalate entire months. Again, I decided with Tcl not to bother. - It appears unnecessary to control skipping the year zero. I have not encountered any locale where there is such a beast; in all cases, it appears that the year 1 B.C.E. is followed by the year 1 C.E. - I use a message catalog (the same catalog in which I hold localised month names) to hold a locale's Julian conversion date, and then select the catalog according to LC_TIME. Tcl's ordinary message catalog functionality can be used to change the date. - I have not yet troubled to implement anything but Gregorian (or hybrid Julian-Gregorian) calendars. I did a limited amount of localization to handle the Japanese civil calendar, but only for dates after the Meiji restoration (when it's Gregorian, except that years number from the start of an emperor's reign). Incidentally, Tcl's counterpart to zic (which uses the same input format as zic) simply uses 64-bit counts of seconds for its transition times. Also, it doesn't track leap seconds, since Tcl's model of time is Markus Kuhn's "smoothed universal time" (http://www.cl.cam.ac.uk/~mgk25/uts.txt) in which leap seconds are handled by changing the length of a second by 1 part in 1000 until Tcl's clock is back in sync with UTC. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

4 3

Re: Time zone: the next generation
by kennykb＠crd.ge.com March 3, 2005

March 3, 2005

I've done a good bit of similar code for the Tcl programming language (see http://www.tcl.tk/cgi-bin/tct/tip/173 for details). The implementation there can handle the proleptic Julian calendar, with a defined change date. There are a number of caveats worth mentioning: - Prior to the Julian conversion, different locales had different rules for when the number of the year changed. In and before 1752 in Great Britain, for instance, the number of the year changed on 25 March; 1-24 March belonged to the previous year! With the adoption of the Gregorian calendar, the change was universally 1 January. (For this reason, you'll sometimes see eighteenth-century dates as O.S. ("Old Style") or N.S. ("New Style") when the year would otherwise be ambiguous. I decided for Tcl not to bother with any kind of localized rule for year numbering in those circumstances; it was too much of a mess. - As you correctly observe, leap years were observed irregularly in Rome in Republican and early Imperial times. In fact, they were so irregularly observed that it was occasionally necessary to intercalate entire months. Again, I decided with Tcl not to bother. - It appears unnecessary to control skipping the year zero. I have not encountered any locale where there is such a beast; in all cases, it appears that the year 1 B.C.E. is followed by the year 1 C.E. - I use a message catalog (the same catalog in which I hold localised month names) to hold a locale's Julian conversion date, and then select the catalog according to LC_TIME. Tcl's ordinary message catalog functionality can be used to change the date. - I have not yet troubled to implement anything but Gregorian (or hybrid Julian-Gregorian) calendars. I did a limited amount of localization to handle the Japanese civil calendar, but only for dates after the Meiji restoration (when it's Gregorian, except that years number from the start of an emperor's reign). Incidentally, Tcl's counterpart to zic (which uses the same input format as zic) simply uses 64-bit counts of seconds for its transition times. Also, it doesn't track leap seconds, since Tcl's model of time is Markus Kuhn's "smoothed universal time" (http://www.cl.cam.ac.uk/~mgk25/uts.txt) in which leap seconds are handled by changing the length of a second by 1 part in 1000 until Tcl's clock is back in sync with UTC. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Timezone Dates for Israel [2005 and beyond]
by Ephraim Silverberg March 2, 2005

March 2, 2005

>From now on, Daylight Saving Time in the State of Israel will commence at 02:00 a.m. on the first Friday before April 2nd and will last until 02:00 a.m. on the first Sunday before the Jewish fast of Yom Kippur. The proposed law amendment can be viewed (for those who read Hebrew) at: ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2005+beyond.ps Note that although the wording of the law is not final, its intent is -- a free translation of the text would read: Every year, between the last Friday of the month of March, at 02:00, and the last Sunday before the tenth of [the Hebrew month of] Tishrei [i.e. the fast of Yom Kippur], at 02:00, the time in Israel will be made one hour earlier so that it will precede Coordinated Universal Time by three hours; in a year that the first of April falls on a Friday, the time will be made earlier, in the manner mentioned, in that year, on this day at 02:00. Attached to this message are the context diffs for "tzdata2005e/asia". I have also update the ZIC entry Emacs generator at: ftp://ftp.cs.huji.ac.il/pub/tz/software/dst-israel.el although it does not use year-range short-hand notation and produces explicit dates for each year. ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-5617723 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cse.huji.ac.il

2 2

Tzcode2005f.tar.gz and tzdata2005f.tar.gz
by Olson, Arthur David (NIH/NCI) March 1, 2005

March 1, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005f.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005f.tar.gz ...are now available; these include the data and documentation changes circulated on the time zone mailing list last week by Paul Eggert. --ado

1 0