- tz - lists.iana.org

Re: tzdata 2003e: imperfections (DST rules)
by Oscar van Vlijmen May 17, 2004

May 17, 2004

> From: "Olson, Arthur David (NIH/NCI)" > Remember that the Rules tell when DST transitions happen; in the above case, > the Rule that's valid is one that specifies the last transition before May > 2004, which is assumed to be in effect in perpetuity. Excerpts from the zic.8 documentation file: " A rule line has the form Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .... TO Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. .... The fields that make up a zone line are: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] .... UNTIL The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a ..... " The Rule and Zone (continuation) lines from the example are: Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S Zone... 9:00 ROK K%sT If I am interpreting the documentation correctly, then the last Zone line says that there is a Rule "ROK" in effect, but for dates after Sunday October 09, 1988 no Rule can be found. The DST rules were changed, so, strictly speaking, and according to the documentation, there should be a new Zone line. For users of the TZ software there is no problem I guess, but developers who can only use the database files, encounter minor problems interpreting the database. Oscar van Vlijmen 2004-05-17

1 0

RE: tzdata 2003e: imperfections
by Olson, Arthur David (NIH/NCI) May 17, 2004

May 17, 2004

> 9:00 ROK K%sT > ... > > Since South Korea no longer observes DST, it would be better for the consistency of the database if the last line was changed into: > 9:00 ROK K%sT 1988 Oct > and an extra line was added, like: > 9:00 - KST Generally speaking, we want to have the last line of a Zone refer to a Rule line. This is particularly important in cases where a country has multiple time zones. If the country decides in the future to change the way DST is handled (for example, decides to start observing DST again), we can make things right by changing one Rule rather than by changing multiple Zones. > The software will give the correct time for e.g. this moment I guess, because no Rule line can be found, valid for May 2004. > So, changing the database files for this could get a low priority, but it is still an imperfection! Remember that the Rules tell when DST transitions happen; in the above case, the Rule that's valid is one that specifies the last transition before May 2004, which is assumed to be in effect in perpetuity. --ado

1 0

Change in Mongolian daylight saving time
by Ganbold April 17, 2004

April 17, 2004

Hello, Current rule settings for Mongolia in /usr/src/share/zoneinfo/asia is wrong. It should be changed from: ... Rule Mongol 2001 only - Apr 27 2:00s 1:00 S Rule Mongol 2001 only - Sep 28 2:00s 0 - ... To the following: ... Rule Mongol 2001 only - Mar lastSat 2:00s 1:00 S Rule Mongol 2001 only - Sep lastSat 2:00s 0 - ... Daylight saving occurs at 02:00 local time last Saturday of March. It will changes back to normal at 02:00 local time last Saturday of September. Please make appropriate changes. Please let me know if you have any questions. sincerely, Ganbold Ts. Mongolia

2 5

Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) April 15, 2004

April 15, 2004

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

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

April 13, 2004

"Steven R. Loomis" <srl(a)jtcsv.com> writes: > Java 1.4 has historical time zones (I believe also from the tz > data?) Thanks for letting me know about this. I looked through the source code (in J2SE-1.4.2/java/src.zip) for this. As far as I can tell, the historical time zone data is in J2SE-1.4.2/j2se/jre/lib/zi, in a format that differs somewhat from the standard Olson format. Also, this information is not in every Java 1.4 implementation, though it is in Sun's. I can't find any supported way to convert from tz format to Java format, so if the Java data are wrong there doesn't seem to be any way to update them from the tz master. Does the following snippet summarize this information correctly? <li><a href="http://java.sun.com/">Sun Java</a> releases since 1.4 contain a copy of a recent <samp>tz</samp> database in a Java-specific format.</li>

2 2

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

April 11, 2004

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

1 0

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

April 9, 2004

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

3 7

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

April 5, 2004

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

1 0

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

April 4, 2004

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

1 0

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

March 29, 2004

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

1 0

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

March 10, 2004

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

1 0

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

March 3, 2004

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

2 2

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

March 2, 2004

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

1 0

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

March 2, 2004

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

1 0

Timezone histories
by John Brehm Feb. 21, 2004

Feb. 21, 2004

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

1 0

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