- tz - lists.iana.org

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

Tzcode2005e.tar.gz and tzdata2005e.tar.gz
by Olson, Arthur David (NIH/NCI) Feb. 10, 2005

Feb. 10, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005e.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005e.tar.gz ...are now available; these incorporate the changes circulated last week on the time zone mailing list. My fond hope is the above code is stable for now; it's time for a design phase to figure out what else (if anything) to do to cope with 64-bit time_t values. Details to follow. --ado

1 0

Re: Israel 2005 and Beyond -- Proposed Timezone Dates
by Paul Eggert Feb. 8, 2005

Feb. 8, 2005

Ephraim Silverberg <ephraim(a)cse.huji.ac.il> writes: > emacs -batch -l dst-israel.el > > ... If the law passes, I'll put the script in the Israel TZ ftp depository. Thanks for doing that! A couple of minor comments. First, the existing database uses "Apr<tab>25" and "Apr<tab><space>9" rather than "Apr<space>25" and "Apr<space><space>9". Also, it'd be a bit handier to input a range of dates rather than a single date. I used your program to write the following draft patch. I don't think this should go into the tz database just yet (Israeli politics being what they are) but I thought you might like to see the draft. Thanks again. --- asia 2004/10/11 18:44:51 2004.5 +++ asia 2004/12/22 23:00:21 @@ -639,7 +639,7 @@ Rule Zion 1988 only - Apr 9 0:00 1:00 D Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> -# (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17 and 2000-07-25): +# (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17, 2000-07-25, and 2004-12-22): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. @@ -690,13 +690,13 @@ Rule Zion 1995 only - Sep 3 0:00 0 S # time, Haim Ramon. The official announcement regarding 1996-1998 # (with the dates for 1997-1998 no longer being relevant) can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # # The dates for 1997-1998 were altered by his successor, Rabbi Eli Suissa. # # The official announcements for the years 1997-1999 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/YYYY.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/YYYY.ps.gz # # where YYYY is the relevant year. @@ -716,12 +716,12 @@ Rule Zion 1999 only - Sep 3 2:00 0 S # # The official announcement for the start date of 2000 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/2000-start.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2000-start.ps.gz # # The official announcement for the end date of 2000 and the dates # for the years 2001-2004 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 2000 only - Apr 14 2:00 1:00 D @@ -735,52 +735,97 @@ Rule Zion 2003 only - Oct 3 1:00 0 S Rule Zion 2004 only - Apr 7 1:00 1:00 D Rule Zion 2004 only - Sep 22 1:00 0 S -# From Paul Eggert (2000-07-25): -# Here are guesses for rules after 2004. -# They are probably wrong, but they are more likely than no DST at all. +# Yesterday, the Knesset Interior Committee passed a proposed (originally +# in March 2004) change to the Time Setting Law that would make the dates +# for DST from 2005 and beyond so that DST starts on the night _after_ the +# first night of the Passover holiday at midnight until midnight of the +# Saturday night _before_ the fast of Yom Kippur. +# +# Those who can read Hebrew can view the proposal at: +# +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2005+.ps +# +# The proposal still has to be passed by the Knesset (three readings) for +# it to become law.... + +# From Paul Eggert (2004-12-22): +# For now, guess that the rules proposed on 2004-12-20 will be adopted. +# This is quite possibly wrong, but it is more likely than no DST at all. +# I used Ed Reingold's cal-hebrew in GNU Emacs 21.3, along with code +# written by Ephraim Silverberg, to generate this list. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Zion 2005 max - Apr 1 1:00 1:00 D -Rule Zion 2005 max - Oct 1 1:00 0 S +Rule Zion 2005 only - Apr 25 0:00 1:00 D +Rule Zion 2005 only - Oct 9 0:00 0 S +Rule Zion 2006 only - Apr 14 0:00 1:00 D +Rule Zion 2006 only - Oct 1 0:00 0 S +Rule Zion 2007 only - Apr 4 0:00 1:00 D +Rule Zion 2007 only - Sep 16 0:00 0 S +Rule Zion 2008 only - Apr 21 0:00 1:00 D +Rule Zion 2008 only - Oct 5 0:00 0 S +Rule Zion 2009 only - Apr 10 0:00 1:00 D +Rule Zion 2009 only - Sep 27 0:00 0 S +Rule Zion 2010 only - Mar 31 0:00 1:00 D +Rule Zion 2010 only - Sep 12 0:00 0 S +Rule Zion 2011 only - Apr 20 0:00 1:00 D +Rule Zion 2011 only - Oct 2 0:00 0 S +Rule Zion 2012 only - Apr 8 0:00 1:00 D +Rule Zion 2012 only - Sep 23 0:00 0 S +Rule Zion 2013 only - Mar 27 0:00 1:00 D +Rule Zion 2013 only - Sep 8 0:00 0 S +Rule Zion 2014 only - Apr 16 0:00 1:00 D +Rule Zion 2014 only - Sep 28 0:00 0 S +Rule Zion 2015 only - Apr 5 0:00 1:00 D +Rule Zion 2015 only - Sep 20 0:00 0 S +Rule Zion 2016 only - Apr 24 0:00 1:00 D +Rule Zion 2016 only - Oct 9 0:00 0 S +Rule Zion 2017 only - Apr 12 0:00 1:00 D +Rule Zion 2017 only - Sep 24 0:00 0 S +Rule Zion 2018 only - Apr 1 0:00 1:00 D +Rule Zion 2018 only - Sep 16 0:00 0 S +Rule Zion 2019 only - Apr 21 0:00 1:00 D +Rule Zion 2019 only - Oct 6 0:00 0 S +Rule Zion 2020 only - Apr 10 0:00 1:00 D +Rule Zion 2020 only - Sep 27 0:00 0 S +Rule Zion 2021 only - Mar 29 0:00 1:00 D +Rule Zion 2021 only - Sep 12 0:00 0 S +Rule Zion 2022 only - Apr 17 0:00 1:00 D +Rule Zion 2022 only - Oct 2 0:00 0 S +Rule Zion 2023 only - Apr 7 0:00 1:00 D +Rule Zion 2023 only - Sep 24 0:00 0 S +Rule Zion 2024 only - Apr 24 0:00 1:00 D +Rule Zion 2024 only - Oct 6 0:00 0 S +Rule Zion 2025 only - Apr 14 0:00 1:00 D +Rule Zion 2025 only - Sep 28 0:00 0 S +Rule Zion 2026 only - Apr 3 0:00 1:00 D +Rule Zion 2026 only - Sep 20 0:00 0 S +Rule Zion 2027 only - Apr 23 0:00 1:00 D +Rule Zion 2027 only - Oct 10 0:00 0 S +Rule Zion 2028 only - Apr 12 0:00 1:00 D +Rule Zion 2028 only - Sep 24 0:00 0 S +Rule Zion 2029 only - Apr 1 0:00 1:00 D +Rule Zion 2029 only - Sep 16 0:00 0 S +Rule Zion 2030 only - Apr 19 0:00 1:00 D +Rule Zion 2030 only - Oct 6 0:00 0 S +Rule Zion 2031 only - Apr 9 0:00 1:00 D +Rule Zion 2031 only - Sep 21 0:00 0 S +Rule Zion 2032 only - Mar 28 0:00 1:00 D +Rule Zion 2032 only - Sep 12 0:00 0 S +Rule Zion 2033 only - Apr 15 0:00 1:00 D +Rule Zion 2033 only - Oct 2 0:00 0 S +Rule Zion 2034 only - Apr 5 0:00 1:00 D +Rule Zion 2034 only - Sep 17 0:00 0 S +Rule Zion 2035 only - Apr 25 0:00 1:00 D +Rule Zion 2035 only - Oct 7 0:00 0 S +Rule Zion 2036 only - Apr 13 0:00 1:00 D +Rule Zion 2036 only - Sep 28 0:00 0 S +Rule Zion 2037 only - Apr 1 0:00 1:00 D +Rule Zion 2037 only - Sep 13 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 2:20:40 - JMT 1918 # Jerusalem Mean Time? 2:00 Zion I%sT -# From Ephraim Silverberg (2003-03-23): -# -# Minister of Interior Poraz has announced that he will respect the law -# passed in July 2000 (proposed at the time jointly by himself and -# then-MK David Azulai [Shas]) fixing the dates for 2000-2004. Hence, -# the dates for 2003 and 2004 remain unchanged.... -# -# As far as 2005 and beyond, no dates have been set. However, the -# minister has mentioned that he wishes to propose to move Israel's -# timezone in 2005 from GMT+2 to GMT+3 and upon that have DST during -# the summer months (i.e. GMT+4). However, no legislation in this -# direction is expected until the latter part of 2004 which is a long -# time off in terms of Israeli politics. - -# (2004-09-20): -# The latest rumour, however, is that in 2005, when the clock changes to -# Daylight Saving Time (date as yet unknown), the move will be a two-hour leap -# forward (from UTC+0200 to UTC+0400) and then, in the fall, the clock will -# move back only an hour to UTC+0300 thus effectively moving Israel's timezone -# from UTC+0200 to UTC+0300. However, no actual draft has been put before the -# Knesset (Israel's Parliament) though the intention is to do so this -# month [2004-09]. - -# (2004-09-26): -# Even though the draft law for the above did pass the Ministerial Committee -# for Legislative Matters three months ago, it was voted down in today's -# Cabinet meeting. The current suggestion is to keep the current timezone at -# UTC+0200 but have an extended period of Daylight Saving Time (UTC+0300) from -# the beginning of Passover holiday in the spring to after the Tabernacle -# holiday in the fall (i.e. the dates of which are governed by the Hebrew -# calendar but this means at least 184 days of DST). However, this is only a -# suggestion that was raised in today's cabinet meeting and has not yet been -# drafted. - ###############################################################################

2 2

FW: IANA time zone registration - proposal
by Olson, Arthur David (NIH/NCI) Feb. 7, 2005

Feb. 7, 2005

Doug Royer is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz(a)lecserver.nci.nih.gov Subject: IANA time zone registration - proposal [This was sent to some IETF mailing lists by me and someone suggested I send it to this list also] This is REV -00 of the proposal - comments welcome. Data in in it can easily updated. (Like the TZ names updated to latest copy of data) ---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF. A copy can be found at: http://inet-consulting.com/draft-royer-timezone-registry-00.txt And an HTML version: http://inet-consulting.com/draft-royer-timezone-registry-00.html I am adding the POLYGON property targeted for the -01 version that has an ADD/DELETE parameter to allow for the optional inclusion of latitude/longitude geographic areas to be included that include (add) and exclude (delete) areas from the time zone geographic region (again from the CALSCH mailing list discussions). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug(a)Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards

7 10