March 2004 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert 25 May '15

25 May '15

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

ftp://elsie.nci.nih.gov/pub/ doesn't work
by Frédéric L. W. Meunier 12 Aug '04

12 Aug '04

I don't know why, but I'm assuming it's because it now rejects connectiong from hosts that don't resolve. Please let me know about any mirrors. -- http://www.pervalidus.net/contact.html

3 2

Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) 14 Apr '04

14 Apr '04

The 2004-03 issue of the U.S. monthly "Discover" has an article titled "Leap Seconds" by Karen Wright(pages 42-45, but the first two pages are décor and an introductory blurb). No mention of the Big Secret (that leap seconds have not been inserted since January of 1999). The article states that "...computer software designers haven't adapted very well to the occasional added second, so experts in air traffic control, satellite communications, and electronic fund transfers have been lobbying to abolish the tinkering. A leap second may have caused the Russian satellite navigation system to crash for hours, and critics claim the added instants could cause commercial airliners to crash as well." The article also notes a couple of modest proposals: "Leap seconds could be inserted every four years along with the February leap day...or leap minutes could be added every half century or so." (Either proposal, if adopted, would require changes in both POSIX and the public-domain time zone code.) 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. --ado

6 8

FW: Update: URL of Time and Date Gateway changed
by Olson, Arthur David (NIH/NCI) 09 Apr '04

09 Apr '04

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

Update: URL of Time and Date Gateway changed
by Peter Thoeny 29 Mar '04

29 Mar '04

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) 10 Mar '04

10 Mar '04

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 03 Mar '04

03 Mar '04

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 02 Mar '04

02 Mar '04

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) 02 Mar '04

02 Mar '04

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