- tz - lists.iana.org

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

FW: Question about: TWiki.org Service: Date and Time Gateway
by Olson, Arthur David (NIH/NCI) Feb. 23, 2005

Feb. 23, 2005

Neither Peter nor Krystian is on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Peter Thoeny [mailto:peter.thoeny@attglobal.net] Sent: Sunday, February 13, 2005 6:23 PM To: krystian(a)mindspring.com; tz(a)lecserver.nci.nih.gov Subject: Re: Question about: TWiki.org Service: Date and Time Gateway Dear Krystian and tz team, The program on TWiki.org takes the data from the Olson tz database, http://www.twinsun.com/tz/tz-link.htm I am not sure I can explain the +/- GMT question, someone from the Olson tz database team is probably better in that. More info on GMT at http://en.wikipedia.org/wiki/GMT Info on timezones at http://wwp.greenwichmeantime.com/info/timezone.htm Interstingly, above site shows GMT times in reverse to the Olson database! E.g. for me in California, the Olson database tells me I am in Etc/GMT+8, and greenwichmeantime.com tells me I am GMT-8. Regards, Confused Peter krystian(a)mindspring.com wrote: > > This question pertains to the data within: > > TWiki.org Service: Date and Time Gateway > http://twiki.org/cgi-bin/xtra/tzdate > > Which I believe is under a revision by your penmanship. > > Q. Are the GMT offsets mixed in this website? When I think of GMT-5 I > think of Eastern Standard Time, however your site lists GMT-5 as where > I always think GMT+5 is. > > > Greenwich Mean Time: (GMT/UCT/UTC/Universal/Zulu; positive numbers > > count hours west of GMT > > What is the cause of having positive numbers count west of GMT? Aren't > positive numbers, by definition, to be east of GMT? (like GMT+5 is add > 5 hours to the time at GMT?) > > I've seen lots of confusion about this on the web and I don't > understand why this is so. I have always thought GMT-5 was Eastern > Standard Time, not some time in the European longitudes. > > Can you please speculate on this? I'm also trying to find the > difference between UTC and GMT (as I've read they are the same but not > exactly). Maybe this is how they differ. > > I'm terribly confused. Please offer an explanation to your readers in > the form of a link or direct them to such a place. > > Regards, > Roland Krystian Alberciak. -- * Peter Thoeny Peter(a)Thoeny.com * Is your team already TWiki enabled? http://TWiki.org * This e-mail is: (_) public (x) ask first (_) private

5 5

Re: Question about: TWiki.org Service: Date and Time Gateway
by Peter Thoeny Feb. 13, 2005

Feb. 13, 2005

Dear Krystian and tz team, The program on TWiki.org takes the data from the Olson tz database, http://www.twinsun.com/tz/tz-link.htm I am not sure I can explain the +/- GMT question, someone from the Olson tz database team is probably better in that. More info on GMT at http://en.wikipedia.org/wiki/GMT Info on timezones at http://wwp.greenwichmeantime.com/info/timezone.htm Interstingly, above site shows GMT times in reverse to the Olson database! E.g. for me in California, the Olson database tells me I am in Etc/GMT+8, and greenwichmeantime.com tells me I am GMT-8. Regards, Confused Peter krystian(a)mindspring.com wrote: > > This question pertains to the data within: > > TWiki.org Service: Date and Time Gateway > http://twiki.org/cgi-bin/xtra/tzdate > > Which I believe is under a revision by your penmanship. > > Q. Are the GMT offsets mixed in this website? When I think of GMT-5 I think > of Eastern Standard Time, however your site lists GMT-5 as where I always > think GMT+5 is. > > > Greenwich Mean Time: (GMT/UCT/UTC/Universal/Zulu; > > positive numbers count hours west of GMT > > What is the cause of having positive numbers count west of GMT? Aren't > positive numbers, by definition, to be east of GMT? (like GMT+5 is add 5 > hours to the time at GMT?) > > I've seen lots of confusion about this on the web and I don't understand why > this is so. I have always thought GMT-5 was Eastern Standard Time, not some > time in the European longitudes. > > Can you please speculate on this? I'm also trying to find the difference > between UTC and GMT (as I've read they are the same but not exactly). Maybe > this is how they differ. > > I'm terribly confused. Please offer an explanation to your readers in the > form of a link or direct them to such a place. > > Regards, > Roland Krystian Alberciak. -- * Peter Thoeny Peter(a)Thoeny.com * Is your team already TWiki enabled? http://TWiki.org * This e-mail is: (_) public (x) ask first (_) private

1 0