February 2002 - tz - lists.iana.org

Serbia and Montenegro
by George Zeigler Feb. 22, 2002

Feb. 22, 2002

Hello, Serbia and Montenegro have united to form "Serbia and Montenegro". Thought the USA refuses to recognize this union, from what I've seen on the internet they consider themselves united. Respective capitals, Belgrade and Podgorica. George

1 0

Russian zones
by George Zeigler Feb. 22, 2002

Feb. 22, 2002

Hello, I live in Russia. Everything here is relative to Moscow time. If this isn't too long for you, then this would be the best way to show the Russian zones. (Moscow -01) Kaliningrad (Moscow +00) Moscow (Moscow +01) Samara (Moscow +02) Yekaterinburg (Moscow +03) Novosibirsk (Moscow +03) Omsk (Moscow +04) Krasnoyarsk (Moscow +05) Irkutsk (Moscow +06) Yakutsk (Moscow +07) Vladivostok (Moscow +07) Sakhalin (Moscow +08) Magadan (Moscow +09) Kamchatka (Moscow +10) Anadyr George PS Leaving the zeros after the + signs helps them to sort properly.

1 0

Macedonia
by George Zeigler Feb. 22, 2002

Feb. 22, 2002

Hello, Macedonia should have it's own section now. Major city Skopje. George

1 0

Indonesia time zones
by George Zeigler Feb. 21, 2002

Feb. 21, 2002

Hello, I think the Indonesia time abbreviations need to be corrected. There should be 3 seperate zones: 1. WIB stand for Waktu Indonesia bagian Barat (Western Indonesian Subtime), 7 hours ahead of GMT 2. WITA stand for Waktu Indonesia bagian Tengah (Medial Indonesian Subtime), 8 hours ahead of GMT 3. WIT stand for Waktu Indonesia bagian Timur (Eastern Indonesian Subtime), 9 hours ahead of GMT http://www.hastu.com/calendar/ Thanks George

1 0

Re: Timezone DST change for Estonia/Tallinn
by Paul Eggert Feb. 21, 2002

Feb. 21, 2002

> From: Toomas Soome [mailto:tsoome@muhv.pri.ee] > Sent: Thursday, February 21, 2002 2:33 PM > > today the Estonian government has changed once again timezone politics. > Now we are useing again EU rules and Estonia/Tallinn description should > be something like: ... > 2:00 - EET 2002 Feb 12 > 2:00 EU EE%sT Thanks for the news. If the rule changed on February 21, I assume that the "Feb 12" is a typo, and it should read "Feb 21" instead?

2 1

FW: Timezone DST change for Estonia/Tallinn
by Olson, Arthur David (NCI) Feb. 21, 2002

Feb. 21, 2002

Toomas Soome is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Toomas Soome [mailto:tsoome@muhv.pri.ee] Sent: Thursday, February 21, 2002 2:33 PM To: tz(a)elsie.nci.nih.gov Subject: Timezone DST change for Estonia/Tallinn hi! today the Estonian government has changed once again timezone politics. Now we are useing again EU rules and Estonia/Tallinn description should be something like: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tallinn 1:39:00 - LMT 1880 1:39:00 - TMT 1918 Feb # Tallinn Mean Time 1:00 C-Eur CE%sT 1919 Jul 1:39:00 - TMT 1921 May 2:00 - EET 1940 Aug 6 3:00 - MSK 1941 Sep 15 1:00 C-Eur CE%sT 1944 Sep 22 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 1:00 EEST 1989 Sep 24 2:00s 2:00 C-Eur EE%sT 1998 Sep 22 2:00 EU EE%sT 1999 Nov 1 2:00 - EET 2002 Feb 12 2:00 EU EE%sT toomas -- To our sweethearts and wives. May they never meet. -- 19th century toast

1 0

Timezone DST change for Estonia/Tallinn
by Toomas Soome Feb. 21, 2002

Feb. 21, 2002

hi! today the Estonian government has changed once again timezone politics. Now we are useing again EU rules and Estonia/Tallinn description should be something like: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tallinn 1:39:00 - LMT 1880 1:39:00 - TMT 1918 Feb # Tallinn Mean Time 1:00 C-Eur CE%sT 1919 Jul 1:39:00 - TMT 1921 May 2:00 - EET 1940 Aug 6 3:00 - MSK 1941 Sep 15 1:00 C-Eur CE%sT 1944 Sep 22 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 1:00 EEST 1989 Sep 24 2:00s 2:00 C-Eur EE%sT 1998 Sep 22 2:00 EU EE%sT 1999 Nov 1 2:00 - EET 2002 Feb 12 2:00 EU EE%sT toomas -- To our sweethearts and wives. May they never meet. -- 19th century toast

1 0

Summer Time Order 2002
by Joseph S. Myers Feb. 21, 2002

Feb. 21, 2002

The Summer Time Order 2002 has appeared in today's Stationery Office Daily List. http://www.legislation.hmso.gov.uk/si/si2002/20020262.htm This implements the 9th Summer Time Directive in the UK on a permanent basis, removing the power to vary Summer Time or introduce Double Summer Time by Order in Council. Unlike previous Orders, it does not apply in Guernsey; I do not know what other provision about Summer Time may have been made there. See also http://www.dti.gov.uk/er/sumtimetb.htm which has the Regulatory Impact Assessment and Transposition Note. -- Joseph S. Myers jsm28(a)cam.ac.uk

1 0

Another C time API proposal
by Markus Kuhn Feb. 21, 2002

Feb. 21, 2002

Perhaps of interest to some here: David R. Tribble: Proposed Standard C (C0X) Calendar Library Functions. http://david.tribble.com/text/c0xcalendar.html Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

New definition of "Seconds Since the Epoch" in POSIX
by Markus Kuhn Feb. 7, 2002

Feb. 7, 2002

The new 2001 edition of the POSIX standard (IEEE Std 1003.1-2001) is now freely available online: http://www.UNIX-systems.org/version3/ Of particular interest to all you leap second gurus out there is perhaps the new slightly revised/relaxed definition of the technical term "Seconds Since the Epoch" that forms the basis for the scalar time used in Unix system calls: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_… A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time are made is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. What has changed? Apart from adding the mod 100 years and mod 400 years leap year rules to the formula, the last two paragraphs have been added. These essentially relax the definition of Seconds Since the Epoch. Without them, a strict interpretation of the old definition would have required that a UTC-aware implementation (e.g., an NTP-synchronized workstation) has to show the same progression of values during an inserted leap second 23:59:60Z and the following first second of the next day 00:00:00Z. In other words, the wording of the old definition could have been interpreted to require UTC-synchronized POSIX clocks to show the same scalar timestamp at 23:59:60.5Z as well as one second later at 00:00:00.5Z, which is indeed what for example the Linux kernel did when connected to a reference clock with activated kernel PLL. The new definition relaxes that and allows for example an implementation to decide to implement the progression of the scalar system time near an inserted leap second by slowing down the system clock briefly, for example according to the formula proposed in http://www.cl.cam.ac.uk/~mgk25/uts.txt As I read it, the new definition still prevents implementations from making the system's scalar time an exact measure of physical time (e.g. by applying the provided encoding formula to a TAI clock display, instead of a UTC clock display) by the requirement of representing each day by an increment of 86400 "seconds" on the scalar clock. (Though nitpickers could of course argue that the text does not explicitely refer to a UTC day, I know :-) Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

2 2