- tz - lists.iana.org

America/Moncton (2007)
by Chris Walton June 27, 2006

June 27, 2006

Recent versions of the Olson database contain a time zone named "America/Moncton". I believe that it was first introduced in version 2006a but I am too lazy to check right now. Before this new time zone was introduced, people in the Canadian province of New Brunswick had to use "America/Halifax"... Halifax being a city in the neighbouring province of Nova Scotia. The new zone was created due to differences in legislation between Nova Scotia and New Brunswick. Current Nova Scotia law dictates the time change takes place at 2:00 a.m. Current New Brunswick law dictates that the time change takes place at 12:01 a.m. On Dec 23/2005 the New Brunswick government committed to follow the US by extending daylight saving by four weeks starting in 2007. The new legislation was assented on June 22/2006. It comes into force on March 1/2007. The new legislation dictates that the time change is to be done at 2:00 a.m. instead of 12:01 a.m. We need to update the Olson Database such that America/Moncton uses the "Canada" rule instead of the "Moncton" rule from 2007 onwards. Here is a link to the "Act to Amend the Time Definition Act" http://www.gnb.ca/0062/acts/BBA-2006/Chap-19.pdf -chris

2 1

Re: Canada timezones (2007)
by Paul Eggert June 26, 2006

June 26, 2006

Robbin Kawabata <Robbin.Kawabata(a)eng.sun.com> writes: > It seems some Canadian provinces have not yet finalized their legislation. Yes. Our current prediction is that they'll fall into line with the US. > Is there any update on what Canadian provinces will do? Not to my knowledge, for time stamps after 1970 anyway. (You're asking us to predict what politicians will do? _Canadian_ politicians? :-) I do anticipate changes for the Bahamas, though; see <http://www.theroyalgazette.com/apps/pbcs.dll/article?AID=/20060506/NEWS/105…>. The only other changes in the pipeline are for historical time stamps (notably Russia before 1992, for which we may need a new zone Europe/Volgograd).

2 1

FW: Extended javascript Date object with support of tz database and xmlDate format
by Olson, Arthur David (NIH/NCI) [E] June 22, 2006

June 22, 2006

Philippe Goetz is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Philippe GOETZ [mailto:philippe.goetz@wanadoo.fr] Sent: Tuesday, June 20, 2006 4:27 PM To: tz(a)lecserver.nci.nih.gov Subject: Extended javascript Date object with support of tz database and xmlDate format Hi all, I'm pleased to make availble to the public an extended javascript Date object with support of tz database and xmlDate format. The page describing the object is: http://mozware.free.fr/devtools/xmlDate/ The code source is available here: http://mozware.free.fr/devtools/xmlDate/xmldate.js Expecting that can help any body. Regards, Philippe GOETZ

2 1

FW: EST is an hour out in zoneinfo
by Olson, Arthur David (NIH/NCI) [E] June 22, 2006

June 22, 2006

Chris Bruner Quadro is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Chris Bruner Quadro [mailto:cbruner@quadro.net] Sent: Wednesday, June 21, 2006 5:14 PM To: tz(a)lecserver.nci.nih.gov Subject: EST is an hour out in zoneinfo EST should give the same results as Canada/Eastern With timezone data of 2006g and glibc of 2.4-r3 created with gentoo Linux. https://bugs.gentoo.org/show_bug.cgi?id=137459 Let me know if you need any additional information. Chris Bruner Compulife Software Inc. ==============================================

2 1

EST is an hour out in zoneinfo
by Chris Bruner Quadro June 21, 2006

June 21, 2006

EST should give the same results as Canada/Eastern With timezone data of 2006g and glibc of 2.4-r3 created with gentoo Linux. https://bugs.gentoo.org/show_bug.cgi?id=137459 Let me know if you need any additional information. Chris Bruner Compulife Software Inc. ==============================================

1 0

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 4:04 PM To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)lecserver.nci.nih.gov; bww(a)acm.org; eggert(a)twinsun.com Subject: RE: zic leapseconds bug I think I chose an example that was rather confusing - mixing the timezone and leapsecond transitions; apologies for that. Try this instead. (start with /usr/local/etc/zoneinfo having the leapsecond version of the tzfiles) % cat <<FOO > xlondon # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London-Test 0:00 EU GMT/BST Rule EU 1995 only - May 21 2:00s 1:00 BST Rule EU 1995 only - Oct 1 2:00s 0 GMT # Note this line; 2 seconds after midnigt Rule EU 1996 only - Jan 1 0:00:02z 1:00 BST Rule EU 1996 only - Jan 2 2:00z 0 GMT FOO % zic -L leapseconds -y yearistype.sh -d /usr/local/etc/zoneinfo zlondon % ./zdump.exe -v Europe/London-Test | fgrep 1996 Europe/London-Test Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London-Test Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London-Test Mon Jan 1 00:00:01 1996 UTC = Mon Jan 1 01:00:01 1996 BST isdst=1 Europe/London-Test Tue Jan 2 01:59:59 1996 UTC = Tue Jan 2 02:59:59 1996 BST isdst=1 Europe/London-Test Tue Jan 2 02:00:00 1996 UTC = Tue Jan 2 02:00:00 1996 GMT isdst=0 See that the BST transition is now 1 second after midnight. David On Tue, 13 Jun 2006, Olson, Arthur David (NIH/NCI) [E] wrote: >> You can't see the problem with zdump, as the transition is not >> visible > to it. But in Europe/London, there was a transition on 1996-01-01 > 00:00:00. >> Here's my dump of the zoneinfo file for the transition & one row > either side of it... > > Here's what I get at elsie; note that the 1995/1996 leap second > transition does seem to be visible to zdump. > > --ado > > Script started on Tue 13 Jun 2006 01:12:41 PM EDT elsie$ cd ~/src/tz > elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- elsie$ ./zdump > -v Europe/London | grep 199[56] Europe/London Sun Mar 26 00:59:59 > 1995 UTC = Sun Mar 26 00:59:59 1995 GMT isdst=0 Europe/London Sun Mar > 26 01:00:00 1995 UTC = Sun Mar 26 02:00:00 1995 BST isdst=1 > Europe/London Sun Oct 22 00:59:59 1995 UTC = Sun Oct 22 01:59:59 1995 > BST isdst=1 Europe/London Sun Oct 22 01:00:00 1995 UTC = Sun Oct 22 > 01:00:00 1995 GMT isdst=0 Europe/London Sun Dec 31 23:59:60 1995 UTC > = Sun Dec 31 23:59:60 1995 GMT isdst=0 Europe/London Mon Jan 1 > 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London > Sun Mar 31 00:59:59 1996 UTC = Sun Mar 31 00:59:59 1996 GMT isdst=0 > Europe/London Sun Mar 31 01:00:00 1996 UTC = Sun Mar 31 02:00:00 1996 > BST isdst=1 Europe/London Sun Oct 27 00:59:59 1996 UTC = Sun Oct 27 > 01:59:59 1996 BST isdst=1 Europe/London Sun Oct 27 01:00:00 1996 UTC > = Sun Oct 27 01:00:00 1996 GMT isdst=0 elsie$ exit > > script done on Tue 13 Jun 2006 01:13:11 PM EDT > > >

1 0

RE: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

> You can't see the problem with zdump, as the transition is not visible to it. But in Europe/London, there was a transition on 1996-01-01 00:00:00. > Here's my dump of the zoneinfo file for the transition & one row either side of it... Here's what I get at elsie; note that the 1995/1996 leap second transition does seem to be visible to zdump. --ado Script started on Tue 13 Jun 2006 01:12:41 PM EDT elsie$ cd ~/src/tz elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- elsie$ ./zdump -v Europe/London | grep 199[56] Europe/London Sun Mar 26 00:59:59 1995 UTC = Sun Mar 26 00:59:59 1995 GMT isdst=0 Europe/London Sun Mar 26 01:00:00 1995 UTC = Sun Mar 26 02:00:00 1995 BST isdst=1 Europe/London Sun Oct 22 00:59:59 1995 UTC = Sun Oct 22 01:59:59 1995 BST isdst=1 Europe/London Sun Oct 22 01:00:00 1995 UTC = Sun Oct 22 01:00:00 1995 GMT isdst=0 Europe/London Sun Dec 31 23:59:60 1995 UTC = Sun Dec 31 23:59:60 1995 GMT isdst=0 Europe/London Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London Sun Mar 31 00:59:59 1996 UTC = Sun Mar 31 00:59:59 1996 GMT isdst=0 Europe/London Sun Mar 31 01:00:00 1996 UTC = Sun Mar 31 02:00:00 1996 BST isdst=1 Europe/London Sun Oct 27 00:59:59 1996 UTC = Sun Oct 27 01:59:59 1996 BST isdst=1 Europe/London Sun Oct 27 01:00:00 1996 UTC = Sun Oct 27 01:00:00 1996 GMT isdst=0 elsie$ exit script done on Tue 13 Jun 2006 01:13:11 PM EDT

1 0

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 1:07 PM To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)lecserver.nci.nih.gov Subject: RE: zic leapseconds bug I should have mentioned that I'm writing my own code to read the compiled zoneinfo files, as specified in tzfile.5. You can't see the problem with zdump, as the transition is not visible to it. But in Europe/London, there was a transition on 1996-01-01 00:00:00. Here's my dump of the zoneinfo file for the transition & one row either side of it: tttime gmtoff isdst abbr issdt isgmt 814323619 +0000 0 GMT 1 1 (1995-10-22 01:00:00) 820454419 +0000 0 GMT 0 0 (should be 1996-01-01 00:00:00) 828234020 +3600 1 BST 1 1 (1996-03-31 01:00:00) leaptime leapcorr 773020818 19 (1994-06-30 23:59:60) 820454419 20 (1995-12-31 23:59:60) 867715220 21 (1997-06-30 23:59:60) The transition time is the same as the leap time for the transition resulting from the switch to the EU rules, i.e. it's one second too early. David On Tue, 13 Jun 2006, Olson, Arthur David (NIH/NCI) [E] wrote: > Here's what's happening with leap seconds now, as divined using zdump: > > Script started on Tue 13 Jun 2006 11:56:20 AM EDT > elsie$ cd ~/src/tz > elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- > elsie$ ./zdump -v America/New_York | grep 1972 > America/New_York Sun Apr 30 06:59:59 1972 UTC = Sun Apr 30 > 01:59:59 1972 EST isdst=0 > America/New_York Sun Apr 30 07:00:00 1972 UTC = Sun Apr 30 03:00:00 > 1972 EDT isdst=1 > America/New_York Fri Jun 30 23:59:60 1972 UTC = Fri Jun 30 19:59:60 > 1972 EDT isdst=1 > America/New_York Sat Jul 1 00:00:00 1972 UTC = Fri Jun 30 20:00:00 > 1972 EDT isdst=1 > America/New_York Sun Oct 29 05:59:59 1972 UTC = Sun Oct 29 > 01:59:59 1972 EDT isdst=1 > America/New_York Sun Oct 29 06:00:00 1972 UTC = Sun Oct 29 01:00:00 > 1972 EST isdst=0 > America/New_York Sun Dec 31 23:59:60 1972 UTC = Sun Dec 31 18:59:60 > 1972 EST isdst=0 > America/New_York Mon Jan 1 00:00:00 1973 UTC = Sun Dec 31 19:00:00 > 1972 EST isdst=0 > elsie$ exit > > script done on Tue 13 Jun 2006 11:56:54 AM EDT > > What should be different? > > --ado

1 0

zic leapseconds bug
by David Robinson June 13, 2006

June 13, 2006

There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

2 1

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 11:07 AM To: tz(a)lecserver.nci.nih.gov Subject: zic leapseconds bug There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

1 0