- tz - lists.iana.org

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

Brazil - update
by Rodrigo Severo Feb. 3, 2004

Feb. 3, 2004

Hi, The Brazilian National Observatory has recently updated/corrected some info about the 1994/1995 DST. According to the new info available the state of Mato Grosso also had DST in this period. I'm sending here a small patch to include the info in tzdata. I used tzdata2003e as my reference. TIA, Rodrigo Severo -- ---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ---------------------------------------------------- diff -cr tzdata2003e/southamerica tzdata2003e.new/southamerica *** tzdata2003e/southamerica 2003-12-15 12:31:42.000000000 -0200 --- tzdata2003e.new/southamerica 2004-02-02 14:51:01.000000000 -0200 *************** *** 536,543 **** # # Mato Grosso (MT) Zone America/Cuiaba -3:44:20 - LMT 1914 - -4:00 Brazil AM%sT 1994 Sep 22 - -4:00 - AMT 1995 Sep 14 -4:00 Brazil AM%sT 2003 Sep 24 -4:00 - AMT # --- 536,541 ----

2 2

FW: Brazil DST data for 2004
by Olson, Arthur David (NIH/NCI) Feb. 2, 2004

Feb. 2, 2004

Otavio Exel is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Otavio Exel [mailto:oexel@economatica.com.br] Sent: Friday, January 30, 2004 1:42 PM To: tz(a)lecserver.nci.nih.gov Subject: Brazil DST data for 2004 Dear TZ, According to http://pcdsh01.on.br/HvInic03.htm DST here in Brazil ends on 2004-02-15 00:00:00 []s, -- Otavio Exel /<\oo/>\ oexel(a)economatica.com.br

2 1

Brazil DST data for 2004
by Otavio Exel Jan. 30, 2004

Jan. 30, 2004

Dear TZ, According to http://pcdsh01.on.br/HvInic03.htm DST here in Brazil ends on 2004-02-15 00:00:00 []s, -- Otavio Exel /<\oo/>\ oexel(a)economatica.com.br

1 0

FW: Time Zone: Malaysia & Singapore
by Olson, Arthur David (NIH/NCI) Jan. 28, 2004

Jan. 28, 2004

Mok Ly Yng is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Mok Ly Yng [mailto:lymok@starhub.net.sg] Sent: Friday, January 23, 2004 9:01 AM To: tz(a)lecserver.nci.nih.gov Subject: Time Zone: Malaysia & Singapore Hi there, I am Mok Ly Yng. I found my name mentioned in the latest version of the tz data file. I have added a few other points to the Malaysia and Singapore time zone info. These are marked in blue. For both Malaysia and Singapore, for many years in the past versions of this file, the first date was listed as 'Until 1880'. This was the date which prompted my research into the history of legal time in Singapore and Malaysia. It turned out that '1880' was the founding year of Kuala Lumpur. So, it could not have been an 'Until' date. Kuala Lumpur kept its own Local Mean Time of 6:46:46 until it was changed to Singapore's Mean Time on 01 Jan 1901, along with the rest of the other Malay States under British rule. The difference of 2 sec between 6:46:46 and 6:46:48 (as in the original version) was probably due to the rounding off of arc seconds in the longitude value. Singapore was founded in 1819 and had kept different local mean times depending on the different longitude values as determined by different authorities over the years. The only uncertainty remaining is the WWII years of 1942-1945. I am still trying to find out the exact dates of time changes. Regards, Mok ========== # @(#)asia 7.73 # Malaysia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 TS # one-Third Summer Rule NBorneo 1935 1941 - Dec 14 0:00 0 - # # peninsular Malaysia # From Paul Eggert (2003-11-01): # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html> >. # Before 1901, Penang, Malacca and Singapore each had their own time zone; # assume Kuala Lumpur used Malaccan time. [This did not happen. K.L. had its own L.M.T. of 6:46:46 from GMT.] # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 # K.L. Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1982 Jan 1 8:00 - MYT # Malaysia Time # Singapore # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html> >. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

2 1

DST history
by Helder & Julie Jan. 23, 2004

Jan. 23, 2004

Could you please let me know when Britain, Canada, and Portugal first began using daylight savings time. I have been looking for that information but seem unable to find it. Thank you.

1 0

Time Zone: Malaysia & Singapore
by Mok Ly Yng Jan. 23, 2004

Jan. 23, 2004

Hi there, I am Mok Ly Yng. I found my name mentioned in the latest version of the tz data file. I have added a few other points to the Malaysia and Singapore time zone info. These are marked in blue. For both Malaysia and Singapore, for many years in the past versions of this file, the first date was listed as 'Until 1880'. This was the date which prompted my research into the history of legal time in Singapore and Malaysia. It turned out that '1880' was the founding year of Kuala Lumpur. So, it could not have been an 'Until' date. Kuala Lumpur kept its own Local Mean Time of 6:46:46 until it was changed to Singapore's Mean Time on 01 Jan 1901, along with the rest of the other Malay States under British rule. The difference of 2 sec between 6:46:46 and 6:46:48 (as in the original version) was probably due to the rounding off of arc seconds in the longitude value. Singapore was founded in 1819 and had kept different local mean times depending on the different longitude values as determined by different authorities over the years. The only uncertainty remaining is the WWII years of 1942-1945. I am still trying to find out the exact dates of time changes. Regards, Mok ========== # @(#)asia 7.73 # Malaysia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 TS # one-Third Summer Rule NBorneo 1935 1941 - Dec 14 0:00 0 - # # peninsular Malaysia # From Paul Eggert (2003-11-01): # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html>. # Before 1901, Penang, Malacca and Singapore each had their own time zone; # assume Kuala Lumpur used Malaccan time. [This did not happen. K.L. had its own L.M.T. of 6:46:46 from GMT.] # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 # K.L. Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1982 Jan 1 8:00 - MYT # Malaysia Time # Singapore # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html>. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

1 0

Time Links
by Murray Triplett Jan. 19, 2004

Jan. 19, 2004

Dear Sir or Madam, My name is Murray Triplett, and I am the webmaster of Instatime.com, an informational site established to educate web users of global time zones. With an easy-to-read world map, all time zones are shown in real time on one page, which is perfect for a quick resource or presentation graphic. I would like to link to do a link exchange with your site (http://www.twinsun.com/tz/tz-link.htm) to improve the users' web experience from both of our ends. Please let me know if this is possible, and if you'd like to move forward. Thank you, Murray Triplett Webmaster, InstaTime __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

Time and time zones on Mars (draft text)
by Paul Eggert Jan. 19, 2004

Jan. 19, 2004

Wednesday's L.A. Times article by Jia-Rui Chong about JPL workers' wristwatches keeping Martian time prompted me to do a little bit of research about time zones on Mars. I'll eventually propose a patch to the "Theory" file, but thought I'd first submit the following rough draft on this mailing list for comment. ----- Time and time zones on Mars ----- Some people have adjusted their work schedules to fit Mars time. Dozens of special Mars watches were built for Jet Propulsion Laboratory workers who kept Mars time during the Mars Exploration Rovers mission (2004). These timepieces look like normal Seikos and Citizens but use Mars seconds rather than terrestrial seconds. A Mars solar day is called a "sol" and has a mean period equal to about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is divided into a conventional 24-hour clock, so each Mars second equals about 1.02749125 terrestrial seconds. The prime meridian of Mars goes through the center of the crater Airy-0, named in honor of the British astronomer who built the Greenwich telescope that defines Earth's prime meridian. Mean solar time on the Mars prime meridian is called Mars Coordinated Time (MTC). Each landed mission on Mars has adopted a different reference for solar time keeping, so there is no real standard for Mars time zones. For example, the Mars Exploration Rovers mission defined two time zones "Local Solar Time A" and "Local Solar Time B" for its two missions, each zone designed so that its time equals local true solar time at approximately the middle of the nominal mission. Such a "time zone" is not particularly suited for any application other than the mission itself. Many calendars have been proposed for Mars, but none have achieved wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a sequential count of Mars solar days elapsed since about 1873-12-29 12:00 GMT. The tz database does not currently support Mars time, but it is documented here in the hopes that support will be added eventually. Sources: Michael Allison and Robert Schmunk, "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" <http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-01-12). Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times <http://www.latimes.com/la-sci-marstime14jan14,1,3346745.story> (2004-01-14), pp A1, A20-A21.

1 0

IERS Bulletin C 27
by Olson, Arthur David (NIH/NCI) Jan. 15, 2004

Jan. 15, 2004

INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : services.iers(a)obspm.fr Paris, 15 January 2004 Bulletin C 27 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of June 2004. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Bulletin C number 27
by iers＠hpopa.obspm.fr Jan. 15, 2004

Jan. 15, 2004

INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : services.iers(a)obspm.fr Paris, 15 January 2004 Bulletin C 27 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of June 2004. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

FW: NebulaSearch.com Encyclopedia article about "Time zone"
by Olson, Arthur David (NIH/NCI) Jan. 12, 2004

Jan. 12, 2004

Bryan Johnston is not on the time zone mailing list; direct replies appropriately. -ado -----Original Message----- From: Bryan Johnston [mailto:nebulasearch@yahoo.com] Sent: Sunday, January 11, 2004 3:57 AM To: tz(a)lecserver.nci.nih.gov Subject: NebulaSearch.com Encyclopedia article about "Time zone" The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

NebulaSearch.com Encyclopedia article about "Time zone"
by Bryan Johnston Jan. 11, 2004

Jan. 11, 2004

The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

24:00; Canada
by Olson, Arthur David (NIH/NCI) Dec. 26, 2003

Dec. 26, 2003

Regarding use of "24:00" in data files (which pre-1998 versions of zic can't handle), Martin Smoot wrote: > I would think at some point that we would have to give up on maintaining compatibility with these older versions of zic. after all it has been several years. how many people do not have a compiler to rebuild zic? Visiting this whole 24:00 business didn't happen because of Kiefer Sutherland/Jack Bauer; we did get a report of difficulty from a user trying to pump updated data files through a vendor-supplied zic. If use of 24:00 was in support of some active time zone, we'd have no choice but to abandon efforts at compatibility, but when the use of 24:00 is only to support a limited number of historic transitions in a limited number of places, there's more motive to avoid use of 24:00 (and thus to avoid problems for folks trying to use the data with existing compilers). We do, of course, want to keep the code in place so that people for whom it would be useful can benefit from it. We face more latency in our work with the time zone stuff than do vendors such as Sun with other software. Sun has to implement and distribute changes and give customers time to adopt them before abandoning support. We have to implement and distribute changes, wait for vendors to implement and distribute them, and then wait for customers to adopt them. So our "give up on maintaining compatibility" time frame is, of necessity, longer than folks might be accustomed to. A complicating factor is that the time zone data files do now get processed by alternate readers that aren't part of the time zone package. At this point we've got the "this is a simpler way to do it" comments in the relevant place in the data file. The next step will be to uncomment that stuff and comment out the more complicated (but more generally useable) stuff. I don't know what the best time frame is for doing that; I imagine it's best to do it before the retirement of yours truly (now 8-1/2 years off). ---------------------------------------------- Another piece of fallout from the 24:00 work was the discovery that back during the Great Depression Toronto was making switches at 2:00 a.m. on the first Sunday after the last Saturday in April and September--even if this meant that the switch got pushed back to May or October. Now as currently set up, when zic is asked to make a switch on a day of the month such as... Sun>=25 ...it checks to ensure that there is indeed such a Sunday in the month and fails if there isn't one. I believe it's reasonable to lift this restriction; doing so allows simpler expression of rules covering situations such as those in Toronto, as witness the (regression-tested) changes attached below. As always, the point of the exercise is not so much to deal with what happened in Toronto way back when, but to be prepared to deal with the situation if some wild-eyed legislators decide to adopt such a scheme in the future. --ado ------- zic.c ------- *** /tmp/geta11385 Mon Dec 22 12:35:17 2003 --- /tmp/getb11385 Mon Dec 22 12:35:18 2003 *************** *** 2138,2144 **** wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0 || i >= len_months[isleap(y)][m]) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } --- 2138,2144 ---- wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } ------- northamerica ------- *** /tmp/geta11403 Mon Dec 22 12:35:18 2003 --- /tmp/getb11403 Mon Dec 22 12:35:18 2003 *************** *** 989,1000 **** # 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 ! 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 ! Rule Toronto 1933 1940 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1933 only - Oct 1 2:00 0 S ! Rule Toronto 1934 1939 - Sep lastSun 2:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D --- 989,998 ---- # 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 ! 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 1939 - Sep lastSun 2:00 0 S ! Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D

2 1

Use of FILENAME_MAX
by Klaus Klein Dec. 20, 2003

Dec. 20, 2003

While investigating a recent NetBSD bug report (related but turned out to be not an issue), I noticed a use of FILENAME_MAX in tzload() which seems a little wrong. With FILENAME_MAX being sufficient to hold the longest valid pathname, including terminating NUL, it is not necessary to allocate an additional character for the separating slash between `p' and `name'; if that character was consumed by the concatenation, the resulting string would no longer be a valid pathname due to its excessive length. I've also taken the liberty to rearrange the component addition below which seems to have had part in causing our original submitter's misunderstanding, but that's merely cosmetics. Just nitpicking, - Klaus *** localtime.c 15 Dec 2003 15:13:53 -0000 1.1.1.9 --- localtime.c 20 Dec 2003 20:09:07 -0000 *************** *** 284,302 **** ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX + 1]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /* --- 284,302 ---- ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + 1 + strlen(name)) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /*

1 0

www.bsdi.com/date is dead; is there a good replacement?
by Paul Eggert Dec. 16, 2003

Dec. 16, 2003

For many years "Sources for Time Zone and Daylight Saving Time Data" <http://www.twinsun.com/tz/tz-link.htm> has referred to "Date and Time Gateway" <http://www.bsdi.com/date/> as a simple text-based point-and-click web interface based on the tz data. However, www.bsdi.com has been refusing connections recently. Apparently Wind River (which acquired BSDI a couple of years ago) has decided to shut down BSD/OS. Too bad. I have located <http://www.earth.com/date/> as another web site that serves the same data, but if BSD/OS is being discontinued then I worry that this is only a stopgap. Can anyone suggest a replacement URL? We currently refer to the following URLs but I'm looking for something that is less fancy and that is oriented towards the tz data. http://www.hilink.com.au/times/ http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP http://timezoneconverter.com/ http://www.holidayfestival.com/ http://www.timeanddate.com/worldclock/

1 0

Tzcode2003e.tar.gz and tzdata2003e.tar.gz
by Olson, Arthur David (NIH/NCI) Dec. 15, 2003

Dec. 15, 2003

The files... ftp://elsie.nci.nih.gov/pub/tzcode2003e.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2003e.tar.gz ...are now available. These include the changes I recently circulated on the time zone mailing list (primarily code changes) as well as the changes circulated by Paul Eggert (primarily data changes). There are also minor changes to "Makefile" and "northamerica" (in the latter case, Optimization of the "Toronto" rules). More on "24:00" and Toronto to follow. --ado

1 0