- tz - lists.iana.org

Re: Chinese timezones
by Gwillim Law June 29, 2006

June 29, 2006

You can find basic information about provincial boundary changes on my "Statoids" site at http://www.statoids.com/ucn.html. The only major changes since 1980: the formation of Hainan province and Chongqing municipality, and the annexation of Hong Kong and Macau. I'll see if I can find anything about the Qinghai-Gansu border. -- Gwillim Law ----- Original Message ----- From: "Paul Eggert" <eggert(a)CS.UCLA.EDU> > Which provincial boundaries have moved since 1980? This knowledge > would help me in my task. For example, > <http://en.wikipedia.org/wiki/Image:China_administrative.png> says > that the Qinghai-Gansu border has moved but gives no details.

1 0

Time Zone Area Polygons
by Brak June 29, 2006

June 29, 2006

I have read at several websites about there being time zone area polygon lists. For example a file called New_Yok.geo. I can't find the files anywhere though. In order to make use of your timezone database, such a database (area polygon) would be needed. Knowing that the New York area is EST isn't sufficient info, as it begs the question "what are the boundaries of this area?" So can you please direct me to where I can download the timezone area polygons. Thanks in advance. B"H John

1 0

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

tzdata Copyright
by Wolber, Richard C June 7, 2006

June 7, 2006

Greetings, Who is considered the "copyright holder" of the tzdata package? ..Chuck.. -- Chuck Wolber (Meriadoc Sandybanks) Electronic Flight Bag Crew Information Systems/ Linux Wonk 253.576.1154 "At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves." - Robertson Davies, The diary of Samuel Marchbanks Clarke, Irwin (1947), XIX, Sunday

1 0

Australian time zone abbreviations
by Chuck Soper June 2, 2006

June 2, 2006

I recently found this Australian government web page on time zones: <http://www.australia.gov.au/about-australia-13time> And this government web page lists time zone names and abbreviations: <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> I have read the notes in the australasia tzdata file. Should the current official time zone abbreviations be used rather than the popular ones? This would be my preference. Perhaps, the older tz abbreviations without the "A" for Australia could be maintained for dates in the past similar to using PWT (Pacific Wartime) for Pacific Time? Thanks, Chuck

5 4

Bern is the Capital of Switzerland
by Didier CLERC June 1, 2006

June 1, 2006

Hello, Why is the timezone for Switzerland Europe/Zurich and not Europe/Bern ? Bern is the Capitale of Switzerland. Considering Zurich to be the capitale of Switzerland is an offense to most of the Swiss. Thank you for your answer, Didier CLERC

1 0

RE: Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month
by Andy Lipscomb June 1, 2006

June 1, 2006

No, in that case at least, the data is correct. The second Saturday of a month can be between the 8th and the 14th, inclusive; this year, the second Saturday of October is the 14th. Since the changeover occurs at 24:00 on that Saturday and Unix doesn't like 24:00, it is coded as 0:00 the following day, which is the 15th this year, and in general can run from the 9th to the 15th. Thus, Sun>=9 is correct. (This is not the "second Sunday," but the "Sunday after the second Saturday." USA readers will see the resemblance to Election Day.) ________________________________ From: Dr Hingston [mailto:dr.hingston@paradise.net.nz] Sent: Wed 31 May 2006 04:31 To: tz(a)lecserver.nci.nih.gov Subject: Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month Dear List Members Woops, seems I got the address wrong, my apologies! I hope this is better! Regarding: Rule Chile 1999 max - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 max - Mar Sun>=9 3:00u 0 - The expression Sun>=9 from the above rules would appear to me to be incorrect, as it suggests the third Sunday in some years. e.g. October this year. Summary: Supreme Decree Number 1,489 (6 October 1970) - This law, enacted during the presidency of Eduardo Frei Montalva, declared that Daylight Saving Time will advance clocks by one hour, beginning the second Saturday of October, and ending the second Saturday of March. Chilean time is administered by the Chilean Navy's Hydrographic and Oceanographic Service (SHOA). On discussion with the Chilean Consulate the above is confirmed, and time for changeover is midnight Saturday (I take to mean 00:00 Sunday)

2 1

Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month
by Dr Hingston May 31, 2006

May 31, 2006

Dear List Members Woops, seems I got the address wrong, my apologies! I hope this is better! Regarding: Rule Chile 1999 max - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 max - Mar Sun>=9 3:00u 0 - The expression Sun>=9 from the above rules would appear to me to be incorrect, as it suggests the third Sunday in some years. e.g. October this year. References: http://www.twinsun.com/tz/tz-link.ht (!) which lists: http://webexhibits.org/daylightsaving/chile.html Summary: Supreme Decree Number 1,489 (6 October 1970) - This law, enacted during the presidency of Eduardo Frei Montalva, declared that Daylight Saving Time will advance clocks by one hour, beginning the second Saturday of October, and ending the second Saturday of March. Chilean time is administered by the Chilean Navy's Hydrographic and Oceanographic Service (SHOA). On discussion with the Chilean Consulate the above is confirmed, and time for changeover is midnight Saturday (I take to mean 00:00 Sunday) It would seem to be correct, to me, if it were stated as Sun>=8. Similarly, if I am correct, then there are quite a number of other instances in the database where the expression Sun>=9 perhaps might be more correctly stated as Sun>=8? Extrapolating further, if I may, some of the other instances may also be incorrect, e.g. Sun>=16 etc. Some examples: Rule ChileAQ 1966 1997 - Oct Sun>=9 0:00 1:00 S Rule Belize 1919 1943 - Feb Sun>=9 0:00 0 S Rule Falk 1985 2000 - Sep Sun>=9 0:00 1:00 S Rule Falk 1986 2000 - Apr Sun>=16 0:00 0 - Rule GB-Eire 1945 1946 - Oct Sun>=2 2:00s 0 GMT Rule GB-Eire 1946 only - Apr Sun>=9 2:00s 1:00 BST Where a week day is stipulated as the Xth day of the month then I believe the correct references should be >=1, >=8, >= 15, >= 22 etc. Therefore I question other numbers, of course they may be correct, however this does seem to suggest careful scrutiny of those numbers is indicated. I'd be grateful for list consideration and comment please. Kind regards David Hingston

1 0

Tzcode2006g.tar.gz and tzdata2006g.tar.gz
by Olson, Arthur David (NIH/NCI) [E] May 31, 2006

May 31, 2006

The files... ftp://elsie.nci.nih.gov/pub/tzcode2006g.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2006g.tar.gz ...are now available; these reflect the northamerica changes circulated last week on the time zone mailing list by Paul Eggert. --ado

2 1

FW: Corrections to latitudes/longitudes in zone.tab
by Olson, Arthur David (NIH/NCI) [E] May 31, 2006

May 31, 2006

Andy McDonald is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Andy McDonald [mailto:andy@stemhaus.com] Sent: Tuesday, May 23, 2006 12:28 AM To: tz(a)lecserver.nci.nih.gov Subject: Corrections to latitudes/longitudes in zone.tab Hi, A very very minor point, but I've run across a few inaccurate latitudes/longitudes in tz's zone.tab (2006g and earlier): Corrected lat/long zone.tab lat/long America/Argentina/Tucuman: -0265000, -0651300 -0312400, -0641100 America/Inuvik: +0682200, -1334400 +0682500, -1133000 America/Rainy_River: +0484300, -0943400 +0484300, -0942900 America/Rankin_Inlet +0624800, -0920500 +0624500, -0921000 America/Scoresbysund: +0703000, -0215800 +0703000, -0221500 (Tucuman's latitude and longitude in zone.tab are those of America/Argentina/Cordoba.) The corrected values come from playing with my Firefox extension (http://www.stemhaus.com/firefox/foxclocks/) and Google Earth, and are of course entirely subjective. Regards, Andy McDonald

3 2

Manpage License question
by Martin Schulze May 30, 2006

May 30, 2006

Hi, the man-pages package for GNU/Linux has incorporated some of the tz manpages that are also distributed in tzcode$year.tar.gz, namely zic.8, zdump.8 and tzselect.8. They lack a copyright notice and a license statement. The tzcode2006g.tar.gz lacks this information as well. What license are these pages distributed under? I assume it's the BSD license, but I'd better ask. Please keep Michael Kerrisk copied who is the current man-pages maintainer, I'm just the Debian downstream. Thanks and kind regards, Joey -- Never trust an operating system you don't have source for!

1 0

Another Windows program that uses the TZ database
by ActiveEarth Sales May 26, 2006

May 26, 2006

Dear tz Contributors, My world time clock software, ActiveEarth, also uses the tz database. Would you add a mention of that to your web page? You can see the software here: http://www.activeearth.com <http://www.activeearth.com/> . There is a new release about to come out that will contain the latest tz data. Thank you so much for this excellent resource! Best regards, Thaine Norris President Norris Family Industry

1 0

new ISO 3166-1 entries
by Chuck Soper May 25, 2006

May 25, 2006

I recently read ISO 3166-1 Newsletter No. V-11 (2006-03-29) and noticed three new ISO 3166-1 entries: GUERNSEY; GG ISLE OF MAN;IM JERSEY;JE I found this rule in the Theory file: Include at least one location per time zone rule set per country. One such location is enough. Use ISO 3166 (see the file iso3166.tab) to help decide whether something is a country. However, uninhabited ISO 3166 regions like Bouvet Island do not need locations, since local time is not defined there. For tzdata, should all populated ISO 3166 regions be included? Does this mean that three new TZ zone descriptions should be added to zone.tab and appropriate data files? Or, should Europe/London be used instead? Should iso3166.tab be updated? Chuck

2 1

C#/.NET tz binary reader ...
by Zbigniew Babiej May 24, 2006

May 24, 2006

Dear Sir or Madam, Recently I have posted the C#/.NET version of tz binary reader at http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=0 C9E8F33-7214-4222-B992-D248D107652F I thought that it would be good idea to share this link on your page as well.... Best Regards, Z. Babiej, MarketXS ______________________________ DISCLAIMER: This e-mail message is intended for the addressee(s) or authorized recipient only. If you are not the addressee, or an authorized recipient, you are specifically advised that any use, distribution, publication, copying or repetition of this information is prohibited. If you have received this information in error, please notify us immediately (+31 (0)20 50 25 800) and destroy this message.

1 0

RE: tz list searchable on Google
by Olson, Arthur David (NIH/NCI) [E] May 23, 2006

May 23, 2006

I'm also worried about spam; that's why electronic mail addresses have been purged from the time zone distribution (and most especially from the source data files such as "northamerica" which end up on millions of computers worldwide). The gmane site's archive of stuff that's gone out on the time zone mailing list extends back to July 2004; has tz-linked spam been seen since then? And...if the gmane mailing list archive is a bad thing, is the elsie ftpable mailing list archive also a bad thing (or is security through difficulty of use sufficient)? --ado

4 4

FW: timezones offset from what?
by Olson, Arthur David (NIH/NCI) [E] May 23, 2006

May 23, 2006

Zefram is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Friday, May 19, 2006 12:30 PM To: tz(a)lecserver.nci.nih.gov Subject: timezones offset from what? I've been doing work on precision timekeeping on computer systems. Naturally I don't use timezones at all inside that code, but there are places where I need to apply timezones when presenting a time to non-specialist humans. Looking through the zoneinfo database and the theory written about it, it struck me that although it deals fantastically with what time offset to use, there's no rigorous treatment of what base time scale to apply the offset to. Then it struck me that a simple treatment of this could solve a couple of other issues with the database. An example of this issue: as the zoneinfo source notes, UK legal time is currently based on mean solar time on the Greenwich meridian. Now that's not even Universal Time any more, since the prime meridian moved (slightly) off the Greenwich meridian. But everyone in the UK in practice sets their clocks based on UTC, as promulgated by the NPL and the BBC. At centisecond timescales, GMT (legal time in the UK), UTC (used in practice), UT1 (which UTC tracks in the long term), and UT2 (used for civil time in the 1950s) are all quite distinct. So I have a suggestion: it would be nice if the zoneinfo database included a field identifying exactly which time scale to apply the offsets to. The database doesn't need to understand how the time scales relate to each other; leave that to the precision horologists. All it needs is a short text string, with values such as "UTC", "UT1", "GMT". Of course, in a lot of cases this information is unavailable, or the distinction wasn't being made, so you'd then give "UT" to be explicitly ambiguous about the exact flavour of Universal Time. This field would also allow the database to handle timezones that are based on something other than UT. Currently the data files for Saudi Arabia attempt to describe apparent solar time in terms of UT, by means of a daily offset change. But it could instead be specified as a fixed offset with a base of apparent solar time on the prime meridian. To understand the zone properly the code would need to calculate the equation of time, but that only needs to be implemented once and it would give a much smoother and more accurate result than the daily UT offset changes do. A system that doesn't do the equation of time would effectively fall back to mean solar time, which is what the Riyadh8X zones do anyway. It's also a way to handle Mars time. Just specify the base to be MTC instead of UT. Ta da. What do you think? -zefram

3 3