- tz - lists.iana.org

ICU and "Sources for Time Zone and Daylight Saving Time Data"
by Paul Eggert April 11, 2004

April 11, 2004

> From: Steven R. Loomis [mailto:srl@jtcsv.com] > Sent: Wednesday, December 03, 2003 8:32 PM > http://oss.software.ibm.com/icu/ Thanks for letting me know about this. Here's a draft description of ICU's use of tz; please let me know of any problems. <li><a href="http://oss.software.ibm.com/icu/">International Components for Unicode (ICU)</a> contains a C/C++ library for internationalization that has a compiler from <samp>tz</samp> source into an ICU-specific format. ICU is freely available under a BSD-style license.</li> By the way do you know about Joda Time? Perhaps you could use it in the Java side of ICU. Here's what I was planning to add for it: <li><a href="http://joda-time.sourceforge.net/">Joda Time - Java date and time API</a> contains a class <code>org.joda.time.tz.ZoneInfoCompiler</code> that compiles <code>tz</code> source into a Joda-specific binary format. Joda Time is freely available under a BSD-style license.</li>

1 0

FW: Update: URL of Time and Date Gateway changed
by Olson, Arthur David (NIH/NCI) April 9, 2004

April 9, 2004

Peter Thoeny is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Peter Thoeny [mailto:peter.thoeny@attglobal.net] Sent: Monday, March 29, 2004 11:37 AM To: tz(a)lecserver.nci.nih.gov Subject: Update: URL of Time and Date Gateway changed Hi, please update the link to "Time and Date Gateway" from http://www.bsdi.com/date to http://TWiki.org/cgi-bin/xtra/tzdate. I am the admin of TWiki.org and inherited the date script from the BSDi folks since their web site is no longer in service. Regards, Peter

3 7

FW: summer / daylight time terminology usage Sydney, AU
by Olson, Arthur David (NIH/NCI) April 5, 2004

April 5, 2004

Darren Blanch is not on the time zone mailing list; direct replies appropriately (and note Darren's request at the end of the message). --ado >From darspam(a)optusnet.com.au Sat Apr 3 05:00:35 2004 Return-Path: <darspam(a)optusnet.com.au> Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [211.29.132.212]) by lecserver.nci.nih.gov (8.12.10/8.12.10) with ESMTP id i33A0X7e005553 for <tz(a)elsie.nci.nih.gov>; Sat, 3 Apr 2004 05:00:34 -0500 (EST) Received: from webmail05.syd.optusnet.com.au (webmail05.syd.optusnet.com.au [211.29.132.239]) by mail008.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i33A0Md32146 for <tz(a)elsie.nci.nih.gov>; Sat, 3 Apr 2004 20:00:26 +1000 Message-Id: <200404031000.i33A0Md32146(a)mail008.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Received: from [211.30.125.100] as user darspam(a)optusnet.com.au by webmail.optusnet.com.au with HTTP; From: darspam(a)optusnet.com.au To: tz(a)lecserver.nci.nih.gov Date: Sat, 03 Apr 2004 20:00:22 +1000 Subject: summer / daylight time terminology usage Sydney, AU Return-Receipt-To: darspam(a)optusnet.com.au Status: RO I found ftp://elsie.nci.nih.gov/pub/ via a reference in rfc2445. The "australasia" document within tzdata2003e.tar.gz made for a specially interesting read. I may be able to add something to the AESD/AEDT/EST/summer/daylight time debate: I am from Sydney, NSW, and have lived there all my life. I distinctly remember from when I was growing up (in the 70s), that people (incl. commercial TV news/weather) used to refer to "EST" for Eastern Standard Time and "DST" for Daylight Savings Time. Weather reports were generally tailored for each city/region so the "Eastern" could be inferred. (This inconsistency disturbed my naturally logical bent, even as a child, which is why I remember it.) However, the phrase "Eastern Summer Time" was also in wide use. These days, AEST and AEDT seem to be widespread, possibly an American influence?? As to the phrase "summer time" versus "daylight time", the locals almost never say "daylight time". Subjectively, I would say that "daylight savings time" is the most common phrase in use, rather than "summer time" (even though the legislation uses "summer time"). Similarly, when talking about start and end dates, we would say "when does daylight savings start?" or "when does daylight saving start?". Note, not "daylight savings time" but "[the practice of] daylight-saving". Regards, Darren R. BLANCH (SN=Blanch,GN=Darren) Blacktown, NSW, Australia dns:darren.blanch.name [Please direct replies to darspam(a)bhsc.nsw.gov.au in addition to darspam(a)optusnet.com.au, since I check the work address more frequently. Also, please don't include my email addresses in any versions of the data file - just "Darren R. Blanch" should suffice if your policies allow.]

1 0

Small correction
by alan＠allm-geodata.com April 4, 2004

April 4, 2004

>From http://www.twinsun.com/tz/tz-link.htm WORLDTIME: interactive atlas, time info, public holidays contains information on local time, sunrise and sunset, and public holidays in several hundred cities around the world. This now comes up with 'The display of holiday information is suspended Best wishes Alan Pritchard The GLOBAL GAZETTEER�: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

1 0

Update: URL of Time and Date Gateway changed
by Peter Thoeny March 29, 2004

March 29, 2004

Hi, please update the link to "Time and Date Gateway" from http://www.bsdi.com/date to http://TWiki.org/cgi-bin/xtra/tzdate. I am the admin of TWiki.org and inherited the date script from the BSDi folks since their web site is no longer in service. Regards, Peter

1 0

FW: Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) March 10, 2004

March 10, 2004

The message below was not forwarded to the list last week since it came from Bradley White's new address; Bradley is now on the list under the new address. --ado ------- Begin Forwarded Message Date: Tue, 02 Mar 2004 12:08:40 -0500 (EST) From: Bradley White <bww(a)acm.org> Subject: Re: Mass media article on leap seconds To: Zone Watchers <tz(a)lecserver.nci.nih.gov> In-Reply-To: Markus' message of Tue, 02 Mar 2004 16:17:48 +0000 ado wrote: > Your correspondent's two cents: in setting up the time handling in UNIX, T&R > got it exactly right with respect to springing forward and falling back when > DST goes in to and out of effect--keep the computer counting monotonically > and leave it to the software to translate the monotonic count into a > representation of local time. What's right at the level of an hour is also > right at the level of a second--keep the computer counting at one count per > second, and leave it to software to figure out what should be displayed when > the user asks what time it is. Markus replied: > I don't agree. There is the important difference that UTC is today very > widely disseminated, whereas TAI is a curiosity only known to time geeks > like us. Keeping a computer synched to something like TAI would only be > practical in the real world if a leap-free timescale (e.g., the existing > TAI or GPS time) were widely enough available, along with a regularly > updated UTC-TAI offset table. Current time distribution services, > however, provide only UTC in easily accessible form, therefore running > machines in TAI would likely cause them to get the leap second offsets > wrong due to out-of-date leap-second tables rather quickly. Their > timestamps would quickly get an integer number of seconds wrong relative > to the timestamps of machines with up-to-date leapsecond tables. I disagree with your disagreement. I ran machines using ado 'right_only' mode and synchronized by NTP, and they sailed smoothly through leaps with no fudging. The NTP code was modified to ignore leap warnings, and to add a single call to time2posix(). If those machines still existed they would still be synchronized no matter whether their leapsecond tables were up- to-date or not (although they would hiccup over leaps they were unaware of). Part of the problem might be in what you refer to as "timestamps". An ado 'right_only' system certainly doesn't believe that its raw time_t is a form useful as an external representation. Bradley ------- End Forwarded Message

1 0

Another tz compiler
by Brian S O'Neill March 3, 2004

March 3, 2004

The main tz project page shows various links to other time zone database formats and other tz compilers. I have been working on the Joda-Time project, which is designed as a replacement for Java's standard date and time classes. It includes a tz compiler and it has its own compact binary format for the resulting files. I would be pleased if the Joda-time project was mentioned on the tz page as well. Joda-Time project: http://joda-time.sourceforge.net/ Compiler (link is unstable): http://joda-time.sourceforge.net/api-0.95/org/joda/time/tz/ZoneInfoCompiler… Most users will have no need to compile the files themselves, as the Joda-Time distribution includes pre-compiled tz files in the jar. The DateTimeZone class knows how to load the files and create objects for them. I finished the tz compiler and new binary format about a year ago. I would have just used Java's standard time zone class, except it did not perform fast enough. Sun's Java v1.4 has a time zone implementation that retrieves offsets using a binary search. Joda-Time's CachedDateTimeZone is faster than a binary search. Caching is handled automatically, and time zones with trivial rules are not wrapped with the cached implementation. It could not be piggybacked onto Java's standard time zone class, as it does not provide a way to iterate over offset transitions. The only documentation on the binary format and the caching is in the source code itself. One of the features in the binary format is that it stores times with variable precision and size. It can store up to millisecond precision, as a 64-bit signed integer. It stores precalculated offset transitions up to the point where a simple DST rule can fully describe all future transitions. Runtime caching is implemented by breaking the time line down into fixed size regions of 2^32 milliseconds, or about 49.7 days. Offset lookup is performed by retrieving one of these regions from the cache. The lookup is performed by shifting out the lower 32 bits of the 64-bit timestamp. This value, modulo 512, is used as an array index to retrieve the region info. A hashtable with 512 regions of 49.7 days provides collision free caching within periods of 69.7 years. The region info object contains a linked list of offset transition instants. Since most regions have less than two transitions, the linked list search is quite fast.

2 2

Re: Mass media article on leap seconds
by Bradley White March 2, 2004

March 2, 2004

ado wrote: > Your correspondent's two cents: in setting up the time handling in UNIX, T&R > got it exactly right with respect to springing forward and falling back when > DST goes in to and out of effect--keep the computer counting monotonically > and leave it to the software to translate the monotonic count into a > representation of local time. What's right at the level of an hour is also > right at the level of a second--keep the computer counting at one count per > second, and leave it to software to figure out what should be displayed when > the user asks what time it is. Markus replied: > I don't agree. There is the important difference that UTC is today very > widely disseminated, whereas TAI is a curiosity only known to time geeks > like us. Keeping a computer synched to something like TAI would only be > practical in the real world if a leap-free timescale (e.g., the existing > TAI or GPS time) were widely enough available, along with a regularly > updated UTC-TAI offset table. Current time distribution services, > however, provide only UTC in easily accessible form, therefore running > machines in TAI would likely cause them to get the leap second offsets > wrong due to out-of-date leap-second tables rather quickly. Their > timestamps would quickly get an integer number of seconds wrong relative > to the timestamps of machines with up-to-date leapsecond tables. I disagree with your disagreement. I ran machines using ado 'right_only' mode and synchronized by NTP, and they sailed smoothly through leaps with no fudging. The NTP code was modified to ignore leap warnings, and to add a single call to time2posix(). If those machines still existed they would still be synchronized no matter whether their leapsecond tables were up- to-date or not (although they would hiccup over leaps they were unaware of). Part of the problem might be in what you refer to as "timestamps". An ado 'right_only' system certainly doesn't believe that its raw time_t is a form useful as an external representation. Bradley

1 0

Proposed change to zic.c and northamerica
by Olson, Arthur David (NIH/NCI) March 2, 2004

March 2, 2004

Getting a jump on DST season, here are proposed minor changes to zic.c and northamerica. The zic.c changes allow rules containing specifications such as... Sun>=25 ...to go past the end of a month; this allows simpler descriptions of the sort of situation that existed in Toronto between 1927 and 1937. Commentary is added to the northamerica file indicating how things could be made simpler, but the data is kept as is to allow folks to continue to use it with pre-2004 versions of zic. (The motive in making the change to zic is to ensure that zic can handle it if some jurisdiction adopts a similar scheme in the future.) --ado ------- zic.c ------- *** /tmp/geta957 Tue Mar 2 10:54:54 2004 --- /tmp/getb957 Tue Mar 2 10:54:55 2004 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.115"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.116"; #include "private.h" #include "locale.h" *************** *** 2139,2146 **** --i; } if (i < 0 || i >= len_months[isleap(y)][m]) { ! error(_("no day in month matches rule")); ! (void) exit(EXIT_FAILURE); } } if (dayoff < 0 && !TYPE_SIGNED(time_t)) --- 2139,2146 ---- --i; } if (i < 0 || i >= len_months[isleap(y)][m]) { ! if (noise) ! warning(_("rule goes past start/end of month--will not work with pre-2004 versions of zic")); } } if (dayoff < 0 && !TYPE_SIGNED(time_t)) ------- northamerica ------- *** /tmp/geta975 Tue Mar 2 10:54:55 2004 --- /tmp/getb975 Tue Mar 2 10:54:55 2004 *************** *** 1,4 **** ! # @(#)northamerica 7.67 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)northamerica 7.68 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, *************** *** 989,994 **** --- 989,1001 ---- # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D + # The 1927-to-1939 rules can be expressed more simply as + # Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S + # Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D + # Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D + # Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S + # The rules below avoid use of Sun>=25 + # (which pre-2004 versions of zic cannot handle). Rule Toronto 1927 1932 - Sep lastSun 2:00 0 S Rule Toronto 1928 1931 - Apr lastSun 2:00 1:00 D Rule Toronto 1932 only - May 1 2:00 1:00 D

1 0

Timezone histories
by John Brehm Feb. 21, 2004

Feb. 21, 2004

Group: Is there a site or resource that I can quickly go to that contains histories of daylight savings date on and off dates for the last 30 years for North American, European, South Africa, and Pacific Rim countries? Thank you, John Brehm

1 0