- tz - lists.iana.org

US changes
by Rives McDow Jan. 16, 2001

Jan. 16, 2001

Dear Paul, Here is an addition for the US. Congress just added Guam and the Northern Marianas to the Uniform Time Act and is calling the time zone, "Chomorro standard time" (This is spelled differently in various sources, and I'm not sure of the final correct spelling.) Rives

10 12

EST
by Alex LIVINGSTON Jan. 15, 2001

Jan. 15, 2001

At 09:06 -0800 2001-01-10, Paul Eggert wrote: > > 1. Is there an "official list" of all the names or labels used to >> designated time zones > >No, unfortunately. And in practice, the names are ambiguous. For >example, "IST" means UTC+2 in Israel, but UTC+5:30 in India. >Simiarly, "EST" has different meanings in the US and in Australia. >Even if you limit yourself to Australia, "EST" can mean UTC+10 or >UTC+11, depending on the time of year. ... and location! Right now, "EST" can mean both UTC+10 and UTC+11, as the state of Queensland does not observe daylight-saving time, whereas the other regions in the eastern time zone do (Victoria, Tasmania, and most of New South Wales). And it's not just because "S" stands for "standard" in the former case and "Summer" in the latter: it stands for "standard" in both cases! Sometimes I'm ashamed to be Australian. _______________ Alex LIVINGSTON IT, Australian Graduate School of Management (AGSM), UNSW SYDNEY NSW 2052 Fax: +61 2 9931-9349 / Phone: +61 2 9931-9264 / Time: UTC + 10 or 11 hours At end of today, Thursday, January 11, time since epoch (1-1-1 at 00:00:00) = 730496 days = 2000.03011698 average Gregorian years time since 2nd millennium, 20th century, 200th decade, 2000th year = 11 days = .03011698 average Gregorian years

2 3

The English Teacher...
by info＠globalcomm.com Jan. 13, 2001

Jan. 13, 2001

1 0

PST
by Alex LIVINGSTON Jan. 11, 2001

Jan. 11, 2001

At 11:07 -0600 2001-01-11, Syed Sajjath wrote: >In our application we always use the abbr., in conjunction with the country, >avoiding ambiguities. More examples are CST, EST and PST used both in >Australia and US. Where/when in Australia is PST used? It doesn't show up anywhere in tzdata2000g. (I haven't downloaded tzdata2000h yet.) _______________ Alex LIVINGSTON IT, Australian Graduate School of Management (AGSM), UNSW SYDNEY NSW 2052 Fax: +61 2 9931-9349 / Phone: +61 2 9931-9264 / Time: UTC + 10 or 11 hours At end of today, Friday, January 12, time since epoch (1-1-1 at 00:00:00) = 730497 days = 2000.03285488 average Gregorian years time since 2nd millennium, 20th century, 200th decade, 2000th year = 12 days = .03285488 average Gregorian years

2 1

Bulletin C number 21
by iers＠hpopa.obspm.fr Jan. 10, 2001

Jan. 10, 2001

INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE 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 : iers(a)obspm.fr Paris, 11 January 2001 Bulletin C 21 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 2001. 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

1 0

TZ-related changes in Draft 5 of the next POSIX standard
by Paul Eggert Jan. 10, 2001

Jan. 10, 2001

The Austin Common Standards Revision Group is drafting the next revision of POSIX, and Draft 5 (d5) is now available; see <http://www.opengroup.org/austin/>. Here are some tz-related changes in this draft: * The TZ string has been extended to allow time zone abbreviations with +, -, and digits, so long as the abbreviations are quoted by angle brackets. For example, the Bourne shell commands TZ='<UTC+10>-10' date; date -u might output the following text: Tue Jan 9 10:30:19 UTC+10 2001 Tue Jan 9 00:30:19 GMT 2001 * Conforming time zone abbreviations are no longer allowed to contain arbitrary characters. Unquoted abbreviations can contain only alphabetic characters in the current locale; quoted ones can also contain digits, '+', and '-'. * Multibyte characters are explicitly allowed in time zone abbreviations, e.g. TZ='AB@-10' might specify an abbreviation 'AB@-' if '@-' is a valid multibyte character in the current locale. * The following declarations are added to <time.h>: char *asctime_r(const struct tm *restrict, char *restrict); char *ctime_r(const time_t *, char *); struct tm *localtime_r(const time_t *restrict, struct tm *restrict); struct tm *gmtime_r(const time_t *restrict, struct tm *restrict); struct tm *getdate(const char *); char *strptime(const char *restrict, const char *restrict, struct tm *restrict); extern int daylight; extern long timezone; * The following declaration is added to <wchar.h>, as per ISO C99: size_t wcsftime(wchar_t *restrict wcs, size_t maxsize, const wchar_t *restrict format, const struct tm *restrict timptr); Here is the TZ-environment-variable-relevant part of the text that has changed; this covers the first three items mentioned above. I have included change bars in the text quoted below. The unchanged part appears in section 8.1.1 of the current POSIX standard. The expanded format (for all TZs whose value does not have a colon as the first character) is as follows: stdoffset[dst[offset][,start[/time],end[/time]]] Where: std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst-such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale. | | Each of these fields may occur in either of two formats quoted or | unquoted: | | - In the quoted form, the first character shall be the less-than | ('<') character and the last character shall be the | greater-than ('>') character. All characters between these | quoting characters shall be alphanumeric characters in the | current locale, the plus-sign ('+') character, or the | minus-sign ('-') character. The std and dst fields in this case | do not include the quoting characters. | | - In the unquoted form, all characters in these fields shall be | alphabetic characters in the current locale. | | The interpretation of these fields is unspecified if either field is | less than three bytes (except for the case when dst is missing), | more than {TZNAME_MAX} bytes, or if they contain characters | other than those specified.

4 3

IERS Message No. 1
by IERS Central Bureau Jan. 2, 2001

Jan. 2, 2001

*************************************************************************** IERS Message No. 1 January 2, 2001 *************************************************************************** Dear IERS contributors and users As of 1 January 2001 the International Earth Rotation Service has got a new structure with the following novelties: - The previous Sections and Sub-Bureaus of the Central Bureau are now autonomous components within the IERS and are called Product Centres. - The Central Bureau moved from Paris to Frankfurt am Main in Germany and has now primarily administrative functions but will operate a data base for the relevant IERS products and data in the future. - New elements of the structure are Combination Research Centres, ITRS Combination Centres and the Analysis Coordinator. - External services like IGS, ILRS and IVS serve as Technique Centres for the IERS. Several new members entered the Directing Board in December 2000, and recently Jan Vondrak was elected new Chairman of the Directing Board to succeed Chris Reigber on January l, 2001. On 1 January 2001 also a new Web site of the IERS went online: www.iers.org All previous IERS Web and ftp servers will remain active, providing information and data to the users. The new Web site www.iers.org, which will be enlarged and improved in the future, shall provide key information on the IERS and its components. It will also link to the IERS components and to other Web sites of interest. This IERS Message is the second in a series of short information on the IERS and its products for contributors and users. This series together with a planned series of IERS Newsletters will replace the IERS Gazettes, issued between 1996 and 2000. More information about the new IERS is given at the new IERS Web site. With kind regards and best wishes for the year 2001, for the IERS Central Bureau Bernd Richter and Wolfgang R. Dick PS: This IERS Message will be sent to all IERS contributors and users for which we have got an e-mail address from the former Central Bureau. In case that you are not interested in receiving future IERS Messages please let us know so your address may be from the mailing list. If you are reading this message at the Web site or elsewhere and wish to be put on the mailing list please send us a short notice. *************************************************************************** IERS Central Bureau Bundesamt fuer Kartographie und Geodaesie Federal Agency of Cartography and Geodesy Richard-Strauss-Allee 11 60598 Frankfurt am Main Germany phone: ++49-69-6333-273 fax: ++49-69-6333-425 e-mail: central_bureau(a)iers.org ***************************************************************************

1 0

None
by Nick Strauss Dec. 31, 2000

Dec. 31, 2000

By my reckoning, Jan. 1, 2001 (Gregorian) Tevet 6, 5761 (Jewish) Shawwal 5, 1421 (Islamic) Pausa 11, 1922 (Indian Civil) 78 xin-Snake Dahan I, 8 (Chinese) Dec 19, 2000 (Julian) Kiyak 23, 1717 (Coptic) Takhas 24, 1994 (Ethiopian) Please tell me, I might have made an arithmetic error. By the way, the Gregorian calendar, to my limited knowledge, doesn't have a year zero. Nick ------------------------------------------------------------ Infinity Software nicks(a)chesco.com http://www.chesco.com/~nicks -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 5.0 for non-commercial use <http://www.pgp.com> mQGiBDdoMKoRBADcw8/3TTYvqLt9X2QXixoLX53ogj7gz3SbiWG49GBniARxq8Xd lRnq3Qq+k4vxsCVCtYRHidbXsRK9BkRgiVfvcJy/JpL/h1V2H2OSrc1Ks0KjUX2v Gb5AWPAg5WVcrNb2xUY5dcjmCRGUi/iXKtwnc+SmhVlM+dzDrbUtw3G9mwCg/4k5 5gkSJnmYEAdaN173UaYD+1cD/3YX/jrVfLD6N6zgFyMxmF/VeL0M1LgqLSw6PfM1 zVyMEHeOZzctgKic9re+r8HQa48b3cUR3zCV/ckt9RHDVqR6qCXmdsJtWKbHP0s+ 8LieGnws9L8nq2lmqDN4PYhHHm7BGToNrZrpdZWGO3vAq8FMiKUPp9nJY3rcTQs5 y6R6A/91Z7YdhpOdiQy2IMZZhLmbSIQ53NYU7C48+RdEUAIkW5l0rtfKA2J5jDi/ s5Q64F04tXkI6CnD8+ljIJ+xEUj8kLnBixeCFoHAprsnM9sGj/+UxRvD2jcQ7ZzH itrtQfU2erwo79imWo7uOERBako6JNv+PG6tqVfyWVbY8ZWXW7QjbmljaG9sYXMg c3RyYXVzcyA8bmNzQGFsdW0ubWl0LmVkdT6JAEsEEBECAAsFAjdoMKoECwMBAgAK CRBl84DJ8rcStH4gAJ4wbHWNlme4+yWVsOV90VRjEyS5TACgg2qnreVqCIjPHhUK 9gLG1/wEcXy5Aw0EN2gwqhAMAMwdd1ckOErixPDojhNnl06SE2H22+slDhf99pj3 yHx5sHIdOHX79sFzxIMRJitDYMPj6NYK/aEoJguuqa6zZQ+iAFMBoHzWq6MSHvoP Ks4fdIRPyvMX86RA6dfSd7ZCLQI2wSbLaF6dfJgJCo1+Le3kXXn11JJPmxiO/Cqn S3wy9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstD qZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryD xUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSR BzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGze MyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1B n5x8vYlLIhkmuquiXsNV6UwybwACAgwAuMKxwz45b36AoTAOW12B4B1sm36qShSj TFipnrN/O7sV03CHdE0hXz1+zHtJUwm+Xt8WYEvrrx3hVT+dKp41HDPAQEkuWCdr EjTiQvN2u37BHhIPpExCjjTzt8UvuhzXAU9+gZVZXzuvFVosqfx7LsngC2NOKGvu BLJkrLh47fJhDrYYu5Vq5myUqARTiUoA/88kJYSDr8lTdTKUoNc9IMsD5wZTRX2s 3NUnS+Wql2yHmY3txF6/LGQO3SYOTBze8rGAxiKEnD7XTKY+6U0X2hSIFMnl9nRP HUkl+/hyyns/b4SpsdM1lv1Sfl9BOCP6ygLV+T6kbThLnCHRtRFQCUDd2R8a3PiH VMetJrYhj6AAIE42Gmuqibeqw1WlvFnzXrwdGHlEWxEZ+Scj+y2wpAuCCABAAPhQ a7t8aIrBW+cnI62FqAmPlPu9xK6pOD5NZ/s3eoNiXxzcbYCxweDv7ypGyYOtSB4a es6fdgCcNWSUZAuBP2OQv+/NGnCyHLmUiQA/AwUYN2gwqmXzgMnytxK0EQJHQQCf Rzkk500k4fkaQiM05xFdxnWaU84AnRbIys57P0JveKdE6Gfa8XjrMHOS =lYII -----END PGP PUBLIC KEY BLOCK----- -- ------------------------------------------------------------ Infinity Software nicks(a)chesco.com http://www.chesco.com/~nicks -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 5.0 for non-commercial use <http://www.pgp.com> mQGiBDdoMKoRBADcw8/3TTYvqLt9X2QXixoLX53ogj7gz3SbiWG49GBniARxq8Xd lRnq3Qq+k4vxsCVCtYRHidbXsRK9BkRgiVfvcJy/JpL/h1V2H2OSrc1Ks0KjUX2v Gb5AWPAg5WVcrNb2xUY5dcjmCRGUi/iXKtwnc+SmhVlM+dzDrbUtw3G9mwCg/4k5 5gkSJnmYEAdaN173UaYD+1cD/3YX/jrVfLD6N6zgFyMxmF/VeL0M1LgqLSw6PfM1 zVyMEHeOZzctgKic9re+r8HQa48b3cUR3zCV/ckt9RHDVqR6qCXmdsJtWKbHP0s+ 8LieGnws9L8nq2lmqDN4PYhHHm7BGToNrZrpdZWGO3vAq8FMiKUPp9nJY3rcTQs5 y6R6A/91Z7YdhpOdiQy2IMZZhLmbSIQ53NYU7C48+RdEUAIkW5l0rtfKA2J5jDi/ s5Q64F04tXkI6CnD8+ljIJ+xEUj8kLnBixeCFoHAprsnM9sGj/+UxRvD2jcQ7ZzH itrtQfU2erwo79imWo7uOERBako6JNv+PG6tqVfyWVbY8ZWXW7QjbmljaG9sYXMg c3RyYXVzcyA8bmNzQGFsdW0ubWl0LmVkdT6JAEsEEBECAAsFAjdoMKoECwMBAgAK CRBl84DJ8rcStH4gAJ4wbHWNlme4+yWVsOV90VRjEyS5TACgg2qnreVqCIjPHhUK 9gLG1/wEcXy5Aw0EN2gwqhAMAMwdd1ckOErixPDojhNnl06SE2H22+slDhf99pj3 yHx5sHIdOHX79sFzxIMRJitDYMPj6NYK/aEoJguuqa6zZQ+iAFMBoHzWq6MSHvoP Ks4fdIRPyvMX86RA6dfSd7ZCLQI2wSbLaF6dfJgJCo1+Le3kXXn11JJPmxiO/Cqn S3wy9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstD qZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryD xUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSR BzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGze MyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1B n5x8vYlLIhkmuquiXsNV6UwybwACAgwAuMKxwz45b36AoTAOW12B4B1sm36qShSj TFipnrN/O7sV03CHdE0hXz1+zHtJUwm+Xt8WYEvrrx3hVT+dKp41HDPAQEkuWCdr EjTiQvN2u37BHhIPpExCjjTzt8UvuhzXAU9+gZVZXzuvFVosqfx7LsngC2NOKGvu BLJkrLh47fJhDrYYu5Vq5myUqARTiUoA/88kJYSDr8lTdTKUoNc9IMsD5wZTRX2s 3NUnS+Wql2yHmY3txF6/LGQO3SYOTBze8rGAxiKEnD7XTKY+6U0X2hSIFMnl9nRP HUkl+/hyyns/b4SpsdM1lv1Sfl9BOCP6ygLV+T6kbThLnCHRtRFQCUDd2R8a3PiH VMetJrYhj6AAIE42Gmuqibeqw1WlvFnzXrwdGHlEWxEZ+Scj+y2wpAuCCABAAPhQ a7t8aIrBW+cnI62FqAmPlPu9xK6pOD5NZ/s3eoNiXxzcbYCxweDv7ypGyYOtSB4a es6fdgCcNWSUZAuBP2OQv+/NGnCyHLmUiQA/AwUYN2gwqmXzgMnytxK0EQJHQQCf Rzkk500k4fkaQiM05xFdxnWaU84AnRbIys57P0JveKdE6Gfa8XjrMHOS =lYII -----END PGP PUBLIC KEY BLOCK-----

1 0

last day of the 2nd millennium
by Alex LIVINGSTON Dec. 31, 2000

Dec. 31, 2000

Today (Sunday, 2000-12-31) is the last day of the the 2nd Gregorian millennium, the 20th Gregorian century, the 200th Gregorian decade, and the 2000th Gregorian year. Happy 3rd millennium! Sorry if this is off topic for the tz discussion list, but for those on it who promote "origin zero", what do you say to the following? Claiming that the epoch of the Gregorian calendar was at the beginning of a year "0" immediately before the year 1 is to fly in the face not only of history but also of the thriving and abundantly tested convention of numbering "1" the first in a sequence of discrete entites, whether periods of time or pages of a newspaper. Outside digital electronics and computing, where the technology justifies them, exceptions to this convention are extremely rare and often questionable. The distinction between numbering the items in a sequence and specifying a quantity, such as the number of billiard balls on a table or the length of a piece of string, is crucial: it has been unavoidable so far in human history and there are no signs that this is about to change. The years of the Gregorian calendar comprise such a sequence: the numbers they are labelled with apply to discrete periods of a whole year, not to a continuum of instants, as for times of day. Their numbering is not, should not, and should not have been, an exception to the rule. Dionysius Exiguus did the right thing (and I'm sure he did have a "concept of zero"). What do you want to call the number-one bestseller and the number-one hit single, and what about the expressions "numero uno", "A1", and even "ace"? How do you want to number children in a family ("my number-0 son"?), lines and verses of a poem or song, volumes of a book, places in a race (0, 1, and 2?), lanes in a swimming pool, houses in a street, faces on dice, cylinders in an engine (think of firing order), weeks of a semester or term and, most glaringly, days of a month and months of a year? Allowing an exceptional "origin zero" for the discrete whole-year periods of a calendar is to defy the KISS principal. In fact, I think the term "origin" is being abused in such a case anyway: in mathematics it applies to the measurement of quantities, not to the numbering of sequences. I've heard this year being referred to as mathematically the last of the old millennium, but emotionally the first of the new. Well, I hope I'm helping to make it emotionally what it is mathematically. _______________ Alex LIVINGSTON Macintosh and Lotus Notes Support / Information Technology (IT) Australian Graduate School of Management (AGSM) UNSW SYDNEY NSW 2052 / Australia Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 Time : UTC+11---[last Mar. Sun.---UTC+10---[last Aug. Sun.---UTC+11--- At end of today, Sunday, December 31, time since epoch (1-1-1 at 00:00:00) = 730485 days = 2000.00000000 average Gregorian years time until 3rd millennium, 21st century, 201st decade, 2001st year = 0 days = .00000000 average Gregorian years

2 1

IERS message No. 0
by IERS Central Bureau Dec. 29, 2000

Dec. 29, 2000

**************************************************************************** * IERS Message No. 0 December, 29 2000 **************************************************************************** * Dear IERS contributors and users As most of you have probably already heard, the International Earth Rotation Service continues its operation from January 1, 2001 onwards with a new structure. This new structure is the result of an extended discussion process for the renewal of the service that had started already in 1996 with a workshop in Paris, resulted in a Call for Participation for the new IERS in 1999 and culminated eventually in the final voting for the composition of the new Directing Board at the 32nd meeting of the old Directing Board in San Francisco in December 2000. After a successful period of more than 10 years of the old IERS, as departing chairman of the old Directing Board I would like to wholeheartedly thank all members of the old Directing Board and the old Central Bureau, but also all contributing individuals and organisations for their untiring efforts carrying out daily routines and also for their support of the planning and decision-taking for renewing the service. I wish the new chairman Jan Vondrak, the new Directing Board and the new Central Bureau the very best success with steering the new IERS and all IERS contributors and users a prosperous and happy year 2001! Sincerely, Christoph Reigber (Chairman of the IERS Directing Board until Dec. 31, 2000) P.S. You will soon receive email information on the new structure of the service from the new Central Bureau. A pre-glance you can take at the homepage of the new IERS at http://www.iers.org/

1 0

Re: why the different MST7MDT zoneinfo files?
by Paul Eggert Dec. 25, 2000

Dec. 25, 2000

> Date: Sun, 24 Dec 2000 10:41:17 -0500 > From: Ben Collins <bcollins(a)debian.org> > > I'm not too familiar with zoneinfo symantics, but I need to follow up on > a Debian bug report. A user noticed these different MST7MDT zoneinfo > files, and that the SystemV ones have the incorrect DST. Why are they > different? Shouldn't the all be the same? > > f1937d0d3ed3a6cf9ca44e04cb4d8509 /usr/share/zoneinfo/MST7MDT > f1937d0d3ed3a6cf9ca44e04cb4d8509 /usr/share/zoneinfo/posix/MST7MDT > 1ac36e9eb32fbeb87af9921ba5b58850 /usr/share/zoneinfo/posix/SystemV/MST7MDT > 65cbdc206e84bf90b10fabb30c13e9b1 /usr/share/zoneinfo/right/MST7MDT > b4885b6a643d6a8c6e5e1f7de5180650 /usr/share/zoneinfo/right/SystemV/MST7MDT > 1ac36e9eb32fbeb87af9921ba5b58850 /usr/share/zoneinfo/SystemV/MST7MDT The SystemV stuff is for compatibility with ancient hosts, none of which must be operating any more, as they mishandle US daylight saving time past 1987. We should obsolete those entries, for the same reason that US/Pacific-PET was removed in 1994: they are far more likely to cause problems than to solve them. The "posix" vs "right" difference is for leap second support. "posix" ignores leap seconds, whereas "right" does not. I suppose we shouldn't just remove the SystemV stuff right away, as there might be some hosts that (mistakenly) use it. But my next proposed patch can replace it with this for now: Link America/Halifax SystemV/AST4ADT Link America/New_York SystemV/EST5EDT Link America/Chicago SystemV/CST6CDT Link America/Denver SystemV/MST7MDT Link America/Los_Angeles SystemV/PST8PDT Link America/Anchorage SystemV/YST9YDT Link America/Puerto_Rico SystemV/AST4 Link America/Indianapolis SystemV/EST5 Link America/Regina SystemV/CST6 Link America/Phoenix SystemV/MST7 Link Pacific/Pitcairn SystemV/PST8 Link Pacific/Gambier SystemV/YST9 Link America/Honolulu SystemV/HST10

1 0

[rfc] why the different MST7MDT zoneinfo files?
by Ben Collins Dec. 24, 2000

Dec. 24, 2000

I'm not too familiar with zoneinfo symantics, but I need to follow up on a Debian bug report. A user noticed these different MST7MDT zoneinfo files, and that the SystemV ones have the incorrect DST. Why are they different? Shouldn't the all be the same? f1937d0d3ed3a6cf9ca44e04cb4d8509 /usr/share/zoneinfo/MST7MDT f1937d0d3ed3a6cf9ca44e04cb4d8509 /usr/share/zoneinfo/posix/MST7MDT 1ac36e9eb32fbeb87af9921ba5b58850 /usr/share/zoneinfo/posix/SystemV/MST7MDT 65cbdc206e84bf90b10fabb30c13e9b1 /usr/share/zoneinfo/right/MST7MDT b4885b6a643d6a8c6e5e1f7de5180650 /usr/share/zoneinfo/right/SystemV/MST7MDT 1ac36e9eb32fbeb87af9921ba5b58850 /usr/share/zoneinfo/SystemV/MST7MDT Thanks, and happy holidays, Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins(a)debian.org -- bcollins(a)openldap.org -- bcollins(a)linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'

1 0

[patch] timezone/zdump.c: combine strings for easier localization
by Ben Collins Dec. 24, 2000

Dec. 24, 2000

(From the Debian bug report) Please apply this (untested) patch so that I can use the correct form of "standard output" in the Finnish message catalog. ("Standard output" alone would be "vakiotuloste" but when used as an object, it must become "vakiotulostetta".) (end bug report) 2000-12-24 Ben Collins <bcollins(a)debian.org> * timezone/zdump.c: Combine strings so that localization is a better. Patch from Kalle Olavi Niemitalo <tosi(a)ees2.oulu.fi> -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins(a)debian.org -- bcollins(a)openldap.org -- bcollins(a)linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'

1 0

tzcode2000h.tar.gz and tzdata2000h.tar.gz
by Olson, Arthur David (NCI) Dec. 23, 2000

Dec. 23, 2000

The files ftp://elsie.nci.nih.gov/pub/tzcode2000h.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2000h.tar.gz are now available. These include the changes circulated by Paul Eggert to the time zone mailing last week, along with one typo fix in the "art" file. With providence, this is the last update of the millenium. --ado

3 3

Savings
by Oscar van Vlijmen Dec. 22, 2000

Dec. 22, 2000

The dictionary says "daylight saving time" (Webster). Several files in the TZ distribution still have "savings" for our daylight! Data folder: asia: 10x australasia: 6x europe: 2x northamerica: 4x southamerica: 1x Code folder: date.c: 1x usno1995, 1997, 1998: each 1x, but one should leave "originals" as is. I cannot produce a diff file, so I hope I may leave this to someone who likes to dot i's. Regards, Oscar van Vlijmen 2000-12-22

2 1

Re: time in France during World War II
by Paul Eggert Dec. 21, 2000

Dec. 21, 2000

> From: "Ciro Discepolo" <discepol(a)tin.it> > Date: Wed, 20 Dec 2000 20:51:12 +0100 > If it can be you useful I point out you a breve (it doesn't > complete) bibliography on the matter treated in our letters. > Henri Le Corre, Régimes Horaires pour le monde entier, Éditions > Traditionnelles - Paris 2 books, 1993 > Gabriel, Traité de l'heure dans le monde, Guy Trédaniel éditeur, Paris, 1991 > Françoise Gauquelin, Problèmes de l'heure résolus en astrologie, Guy > trédaniel, Paris 1987 Thanks; I'll add a comment about these. > As you can read from the attached file, according to Le Corre, and > according to also other authors, in France, in 1943, there was a > double daylight saving time, both in the busy zones and in the zones > freed by the Germans. Le Corre is not consistent about whether he means local time or Universal Time. I think most of his data use Universal Time, but his first line "Du 15/03/1891, 0h01 au 11/03/1911, 0h01 = GMT + 0h09m21s" must be referring to local time; it wouldn't make sense as Universal Time. Three years ago Denis Excoffier checked our tables against the Ephemerides Astronomiques for 1998 from Bureau des Longitudes. I recall that an advantage of that source is that it explicitly gives the Universal Time for each transition. Unfortunately it is not available on the web as far as I know. I don't recall what it had to say about Paris during the war, either, unfortunately. Assuming Le Colle means Universal Time for most times, I see the following discrepancies between your attached page and our current tables: * Shanks has the 1911 switch at 1911-03-11 00:00; Le Corre has it at 00:01. Let's go with Le Corre here, since he has more detail. * The transitions between 1976 and 1978 are a hodgepodge. I think our tables agree with Le Corre only if we assume some of Le Corre's times are local time, and some are UTC; but this doesn't really make sense. I'd rather get some confirming data. * Shanks writes that Paris observed German time under occupation, whereas Le Corre has it observing the same as Vichy time starting on 1942-11-02. This is the discrepancy that you observe. I am inclined to agree with Le Corre. * Shanks writes that Paris reverted to the previous French rules between 1944-08-25 and 1945-09-16, whereas Le Corre has Paris continuing to observe the same time as occupied France. Here Shanks's story seems more plausible, though of course Le Corre could be right as well. I wish I had confirmation of Le Corre's data, or knew where he got his information from. Are there references in his book for this data?

1 0

Re: Some little errors
by Paul Eggert Dec. 20, 2000

Dec. 20, 2000

> From: "Ciro Discepolo" <discepol(a)tin.it> > Date: Tue, 19 Dec 2000 17:35:44 +0100 > From a lot of specialist books (for example Le Corre's book or > Gabriel's book) I receive the information that in France, in the year > 1943, and precisely from October 4, there was a double daylight saving > time. Can you please give more precise references? I'm not familiar with those books. The discrepancy may be due to which part of France you're talking about. Our current database (taken from Shanks; see below) has Vichy France using double daylight saving time (DDST) from 03-29 02:00 to 10-04 03:00 that year, so we agree about the DDST there. According to Shanks, Occupied France used German time, which meant the same wall-clock time but with different underlying rules. German time was an hour ahead of UTC, with single DST during summer. Vichy France time was at UTC, with single DST in winter and double DST in summer. (It is a bit odd that we have better data for France in 1944 than we do for Palestine in 2000; but that's how the cookie is crumbling.) > In Italy, in 1944, there was a double situation: in the northern cities > of the Gothic line (around Bologna) daylight saving time was excluded on > October 2. Instead, in the southern cities of Gothic line, this daylight > saving time, was excluded on September 17. Yes, that's quite plausible. Northern Italy was still running on German time. However, we don't need a separate entry for Bologna since it is in the same country as Rome and has used the same time rules since 1970, our cutoff date. Did San Marino use the same rules as Rome back then? Currently our database says that it does. That might need correcting. > In Italy, after 1866, the whole nation was divided in three parts: the > continental part, the Sicily part and the Sardinia part, with three > different time zones. You can read about it in the Regio Decreto (king > decree) number 3224 in the year 1866. I think I'll add a comment like this to the file, to help make things clearer: # From Paul Eggert (2000-12-19): # Sicily and Sardinia each had their own time zones from 1866 to 1893. # During World War II, German-controlled Italy used German time. # But these events all occurred before our 1970 cutoff, # so we need to record only the time in Rome. > But, if you have forgotten these items, it is even possible that there > are many others items left out? Many items are left out. Please see the "Theory" file and look for the string "1970". > Please, I have another little query for you: do you know a software or a > DLL (library) that includes all the correct world time-zones? Sorry, there is no such thing. But you might look for "Shanks" in the tz-link.htm file; he has perhaps the best historical database right now. > ------=_NextPart_000_00A5_01C069E2.1DAE6E30 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable Can you please fix your copy of Outlook Express so that you send text mail as plain text, and not as MIME multipart? That makes it easier for others to read. I get lots of email, and html is harder to process than plain text. Thanks.

3 2

FW: Some little errors
by Olson, Arthur David (NCI) Dec. 19, 2000

Dec. 19, 2000

Ciro Discepolo is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Ciro Discepolo [mailto:discepol@tin.it] Sent: Tuesday, December 19, 2000 11:36 AM To: tz(a)elsie.nci.nih.gov Subject: Some little errors Dear Sirs,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> I'd like to give you my compliments for your enormous work in the time-zone file of the whole world. I am working on this file to obtain a second file for one of mine specific applications. Unfortunately I have found some little errors or I think that these are some errors. I'd like to explain these points. First of all >From a lot of specialist books (for example Le Corre's book or Gabriel's book) I receive the information that in France, in the year 1943, and precisely from October 4, there was a double daylight saving time. This fact is not present in your database as you can see lower: # France # # Shanks seems to use `24:00' ambiguously; we resolve it with Whitman. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule France 1916 only - Jun 14 23:00s 1:00 S Rule France 1916 1919 - Oct Sun>=1 23:00s 0 - Rule France 1917 only - Mar 24 23:00s 1:00 S Rule France 1918 only - Mar 9 23:00s 1:00 S Rule France 1919 only - Mar 1 23:00s 1:00 S Rule France 1920 only - Feb 14 23:00s 1:00 S Rule France 1920 only - Oct 23 23:00s 0 - Rule France 1921 only - Mar 14 23:00s 1:00 S Rule France 1921 only - Oct 25 23:00s 0 - Rule France 1922 only - Mar 25 23:00s 1:00 S # DSH writes that a law of 1923-05-24 specified 3rd Sat in Apr at 23:00 to 1st # Sat in Oct at 24:00; and that in 1930, because of Easter, the transitions # were Apr 12 and Oct 5. Go with Shanks. Rule France 1922 1938 - Oct Sat>=1 23:00s 0 - Rule France 1923 only - May 26 23:00s 1:00 S Rule France 1924 only - Mar 29 23:00s 1:00 S Rule France 1925 only - Apr 4 23:00s 1:00 S Rule France 1926 only - Apr 17 23:00s 1:00 S Rule France 1927 only - Apr 9 23:00s 1:00 S Rule France 1928 only - Apr 14 23:00s 1:00 S Rule France 1929 only - Apr 20 23:00s 1:00 S Rule France 1930 only - Apr 12 23:00s 1:00 S Rule France 1931 only - Apr 18 23:00s 1:00 S Rule France 1932 only - Apr 2 23:00s 1:00 S Rule France 1933 only - Mar 25 23:00s 1:00 S Rule France 1934 only - Apr 7 23:00s 1:00 S Rule France 1935 only - Mar 30 23:00s 1:00 S Rule France 1936 only - Apr 18 23:00s 1:00 S Rule France 1937 only - Apr 3 23:00s 1:00 S Rule France 1938 only - Mar 26 23:00s 1:00 S Rule France 1939 only - Apr 15 23:00s 1:00 S Rule France 1939 only - Nov 18 23:00s 0 - Rule France 1940 only - Feb 25 2:00 1:00 S # The French rules for 1941-1944 were not used in Paris, # but were used in other places (e.g. Monaco). Rule France 1941 only - May 5 0:00 2:00 M # Midsummer # Shanks says this transition occurred at Oct 6 1:00, # but go with Denis.Excoffier(a)ens.fr (1997-12-12), # who quotes the Ephemerides Astronomiques for 1998 from Bureau des Longitudes # as saying 5/10/41 22hUT. Rule France 1941 only - Oct 6 0:00 1:00 S Rule France 1942 only - Mar 9 0:00 2:00 M Rule France 1942 only - Nov 2 3:00 1:00 S Rule France 1943 only - Mar 29 2:00 2:00 M Rule France 1943 only - Oct 4 3:00 1:00 S Rule France 1944 only - Apr 3 2:00 2:00 M Rule France 1944 only - Oct 8 1:00 1:00 S Rule France 1945 only - Apr 2 2:00 2:00 M Rule France 1945 only - Sep 16 3:00 0 - # Shanks gives Mar 28 2:00 and Sep 26 3:00; # go with Excoffier's 28/3/76 0hUT and 25/9/76 23hUT. Rule France 1976 only - Mar 28 1:00 1:00 S Rule France 1976 only - Sep 26 1:00 0 - # Shanks gives 0:09 for Paris Mean Time, and Whitman gives 0:09:05, # but Howse quotes the actual French legislation as saying 0:09:21. # Go with Howse. Howse writes that the time in France was officially based # on PMT-0:09:21 until 1978-08-09, when the time base finally switched to UTC. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time # Shanks gives 1940 Jun 14 0:00; go with Excoffier's 14/6/40 22hUT. 0:00 France WE%sT 1940 Jun 14 23:00 1:00 C-Eur CE%sT 1944 Aug 25 0:00 France WE%sT 1945 Sep 16 3:00 1:00 France CE%sT 1977 1:00 EU CE%sT The second fact In Italy, in 1944, there was a double situation: in the northern cities of the Gothic line (around Bologna) daylight saving time was excluded on October 2. Instead, in the southern cities of Gothic line, this daylight saving time, was excluded on September 17. This historic reference has been proven by the Gazzetta Ufficiale (Official Government Journal). But this reference is not in your database. The third fact In Italy, after 1866, the whole nation was divided in three parts: the continental part, the Sicily part and the Sardinia part, with three different time zones. You can read about it in the Regio Decreto (king decree) number 3224 in the year 1866. But even this aspect is not present in your work. Now I am asking myself: maybe I have not read well or these notices could have beeen left out by you? But, if you have forgotten these items, it is even possible that there are many others items left out? Please, I have another little query for you: do you know a software or a DLL (library) that includes all the correct world time-zones? Or, is there, on the web, a more recent release or your database with these corrections about the examples that I have made before? Excuse me for disturbing you and I send you many regards and a Merry Christmas and a Happy New Year Ciro Discepolo www.cirodiscepolo.it <http://www.cirodiscepolo.it> discepol(a)tin.it <mailto:discepol@tin.it>

1 0

Some little errors
by Ciro Discepolo Dec. 19, 2000

Dec. 19, 2000

Dear Sirs, I'd like to give you my compliments for your enormous work in the time-zone file of the whole world. I am working on this file to obtain a second file for one of mine specific applications. Unfortunately I have found some little errors or I think that these are some errors. I'd like to explain these points. First of all >From a lot of specialist books (for example Le Corre's book or Gabriel's book) I receive the information that in France, in the year 1943, and precisely from October 4, there was a double daylight saving time. This fact is not present in your database as you can see lower: # France # # Shanks seems to use `24:00' ambiguously; we resolve it with Whitman. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule France 1916 only - Jun 14 23:00s 1:00 S Rule France 1916 1919 - Oct Sun>=1 23:00s 0 - Rule France 1917 only - Mar 24 23:00s 1:00 S Rule France 1918 only - Mar 9 23:00s 1:00 S Rule France 1919 only - Mar 1 23:00s 1:00 S Rule France 1920 only - Feb 14 23:00s 1:00 S Rule France 1920 only - Oct 23 23:00s 0 - Rule France 1921 only - Mar 14 23:00s 1:00 S Rule France 1921 only - Oct 25 23:00s 0 - Rule France 1922 only - Mar 25 23:00s 1:00 S # DSH writes that a law of 1923-05-24 specified 3rd Sat in Apr at 23:00 to 1st # Sat in Oct at 24:00; and that in 1930, because of Easter, the transitions # were Apr 12 and Oct 5. Go with Shanks. Rule France 1922 1938 - Oct Sat>=1 23:00s 0 - Rule France 1923 only - May 26 23:00s 1:00 S Rule France 1924 only - Mar 29 23:00s 1:00 S Rule France 1925 only - Apr 4 23:00s 1:00 S Rule France 1926 only - Apr 17 23:00s 1:00 S Rule France 1927 only - Apr 9 23:00s 1:00 S Rule France 1928 only - Apr 14 23:00s 1:00 S Rule France 1929 only - Apr 20 23:00s 1:00 S Rule France 1930 only - Apr 12 23:00s 1:00 S Rule France 1931 only - Apr 18 23:00s 1:00 S Rule France 1932 only - Apr 2 23:00s 1:00 S Rule France 1933 only - Mar 25 23:00s 1:00 S Rule France 1934 only - Apr 7 23:00s 1:00 S Rule France 1935 only - Mar 30 23:00s 1:00 S Rule France 1936 only - Apr 18 23:00s 1:00 S Rule France 1937 only - Apr 3 23:00s 1:00 S Rule France 1938 only - Mar 26 23:00s 1:00 S Rule France 1939 only - Apr 15 23:00s 1:00 S Rule France 1939 only - Nov 18 23:00s 0 - Rule France 1940 only - Feb 25 2:00 1:00 S # The French rules for 1941-1944 were not used in Paris, # but were used in other places (e.g. Monaco). Rule France 1941 only - May 5 0:00 2:00 M # Midsummer # Shanks says this transition occurred at Oct 6 1:00, # but go with Denis.Excoffier(a)ens.fr (1997-12-12), # who quotes the Ephemerides Astronomiques for 1998 from Bureau des Longitudes # as saying 5/10/41 22hUT. Rule France 1941 only - Oct 6 0:00 1:00 S Rule France 1942 only - Mar 9 0:00 2:00 M Rule France 1942 only - Nov 2 3:00 1:00 S Rule France 1943 only - Mar 29 2:00 2:00 M Rule France 1943 only - Oct 4 3:00 1:00 S Rule France 1944 only - Apr 3 2:00 2:00 M Rule France 1944 only - Oct 8 1:00 1:00 S Rule France 1945 only - Apr 2 2:00 2:00 M Rule France 1945 only - Sep 16 3:00 0 - # Shanks gives Mar 28 2:00 and Sep 26 3:00; # go with Excoffier's 28/3/76 0hUT and 25/9/76 23hUT. Rule France 1976 only - Mar 28 1:00 1:00 S Rule France 1976 only - Sep 26 1:00 0 - # Shanks gives 0:09 for Paris Mean Time, and Whitman gives 0:09:05, # but Howse quotes the actual French legislation as saying 0:09:21. # Go with Howse. Howse writes that the time in France was officially based # on PMT-0:09:21 until 1978-08-09, when the time base finally switched to UTC. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time # Shanks gives 1940 Jun 14 0:00; go with Excoffier's 14/6/40 22hUT. 0:00 France WE%sT 1940 Jun 14 23:00 1:00 C-Eur CE%sT 1944 Aug 25 0:00 France WE%sT 1945 Sep 16 3:00 1:00 France CE%sT 1977 1:00 EU CE%sT The second fact In Italy, in 1944, there was a double situation: in the northern cities of the Gothic line (around Bologna) daylight saving time was excluded on October 2. Instead, in the southern cities of Gothic line, this daylight saving time, was excluded on September 17. This historic reference has been proven by the Gazzetta Ufficiale (Official Government Journal). But this reference is not in your database. The third fact In Italy, after 1866, the whole nation was divided in three parts: the continental part, the Sicily part and the Sardinia part, with three different time zones. You can read about it in the Regio Decreto (king decree) number 3224 in the year 1866. But even this aspect is not present in your work. Now I am asking myself: maybe I have not read well or these notices could have beeen left out by you? But, if you have forgotten these items, it is even possible that there are many others items left out? Please, I have another little query for you: do you know a software or a DLL (library) that includes all the correct world time-zones? Or, is there, on the web, a more recent release or your database with these corrections about the examples that I have made before? Excuse me for disturbing you and I send you many regards and a Merry Christmas and a Happy New Year Ciro Discepolo www.cirodiscepolo.it discepol(a)tin.it

1 0

RE: Book on time
by Olson, Arthur David (NCI) Dec. 19, 2000

Dec. 19, 2000

> From: alan(a)allm-geodata.com [mailto:alan@allm-geodata.com] > Sent: Thursday, December 14, 2000 8:53 AM > ... > I came across this book in my local bookshop. It may be of interest > > Clark, Blaise > Time lord: Sir Sandford Fleming and the creation of standard time > Wiedenfeld & Nicholson, 2000. > ... The publisher for the United States of America is Random House; publication is due in March of 2001. --ado

1 0

Time Zone Converter
by Gina Carollo Dec. 15, 2000

Dec. 15, 2000

Hello. I need to convert a date/time and I am having a hard time figuring out how to do it. I want to convert from one time zone to another but I need to make it possible to convert from any timezone to any time zone. Do your applications use java to do your conversions? Can you put me in the right direction to figure out how to do it? I would really appreciate any help you can give me. Thank you. Gina Carollo gcarollo(a)crowechizek.com

1 0

RE: Expired Rules: How Should They Be Handled
by Olson, Arthur David (NCI) Dec. 14, 2000

Dec. 14, 2000

> I have written some software to reduce the "tzdata" files down > to their current GMTOFF values with associated Rule usage. The > software ends up acting as an integrity check on the database, > i.e. it coughs up current expired Rule usage. The following > Rules, which are current Rule in the indicated Zones, have all > expired. How should/are these Zones handled if a user does > a "setenv TZ " of one of them? > > Dave Skinner > dave(a)nurh.jpl.nasa.gov > ... > Rule Ghana > Zone Africa/Accra > ... > Rule Tunisia > Zone Africa/Tunis Pertinent stuff from the "africa" file is... # Ghana # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman says DST was observed from 1931 to ``the present''; go with Shanks. Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s ...so, indeed, time in Accra is calculated the same way at all instants from the end of 1942 forward. However, the rule is kept to allow proper handling of historic instants. Doing so is more important in a case such as... ... Rule Tunisia 1988 1990 - Sep lastSun 0:00s 0 - Rule Tunisia 1989 only - Mar 26 0:00s 1:00 S Rule Tunisia 1990 only - May 1 0:00s 1:00 S # Shanks gives 0:09 for Paris Mean Time; go with Howse's more precise 0:09:21. # Shanks says the 1911 switch occurred on Mar 9; go with Howse's Mar 11. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Tunis 0:40:44 - LMT 1881 May 12 0:09:21 - PMT 1911 Mar 11 1:00 Tunisia CE%sT ...where there were clock changes as late as 1990--after the UNIX epoch. If you didn't keep the rules, running a program such as zdump would produce the wrong output rather than what's shown below. --ado Script started on Thu Dec 14 16:07:09 2000 flower$ ./zdump -v Africa/Accra Africa/Tunis Africa/Accra Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:00 1901 LMT isdst=0 Africa/Accra Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:00 1901 LMT isdst=0 Africa/Accra Tue Jan 1 00:00:51 1918 UTC = Mon Dec 31 23:59:59 1917 LMT isdst=0 Africa/Accra Tue Jan 1 00:00:52 1918 UTC = Tue Jan 1 00:00:52 1918 GMT isdst=0 Africa/Accra Mon Aug 31 23:59:59 1936 UTC = Mon Aug 31 23:59:59 1936 GMT isdst=0 Africa/Accra Tue Sep 1 00:00:00 1936 UTC = Tue Sep 1 00:20:00 1936 GHST isdst=1 Africa/Accra Wed Dec 30 23:39:59 1936 UTC = Wed Dec 30 23:59:59 1936 GHST isdst=1 Africa/Accra Wed Dec 30 23:40:00 1936 UTC = Wed Dec 30 23:40:00 1936 GMT isdst=0 Africa/Accra Tue Aug 31 23:59:59 1937 UTC = Tue Aug 31 23:59:59 1937 GMT isdst=0 Africa/Accra Wed Sep 1 00:00:00 1937 UTC = Wed Sep 1 00:20:00 1937 GHST isdst=1 Africa/Accra Thu Dec 30 23:39:59 1937 UTC = Thu Dec 30 23:59:59 1937 GHST isdst=1 Africa/Accra Thu Dec 30 23:40:00 1937 UTC = Thu Dec 30 23:40:00 1937 GMT isdst=0 Africa/Accra Wed Aug 31 23:59:59 1938 UTC = Wed Aug 31 23:59:59 1938 GMT isdst=0 Africa/Accra Thu Sep 1 00:00:00 1938 UTC = Thu Sep 1 00:20:00 1938 GHST isdst=1 Africa/Accra Fri Dec 30 23:39:59 1938 UTC = Fri Dec 30 23:59:59 1938 GHST isdst=1 Africa/Accra Fri Dec 30 23:40:00 1938 UTC = Fri Dec 30 23:40:00 1938 GMT isdst=0 Africa/Accra Thu Aug 31 23:59:59 1939 UTC = Thu Aug 31 23:59:59 1939 GMT isdst=0 Africa/Accra Fri Sep 1 00:00:00 1939 UTC = Fri Sep 1 00:20:00 1939 GHST isdst=1 Africa/Accra Sat Dec 30 23:39:59 1939 UTC = Sat Dec 30 23:59:59 1939 GHST isdst=1 Africa/Accra Sat Dec 30 23:40:00 1939 UTC = Sat Dec 30 23:40:00 1939 GMT isdst=0 Africa/Accra Sat Aug 31 23:59:59 1940 UTC = Sat Aug 31 23:59:59 1940 GMT isdst=0 Africa/Accra Sun Sep 1 00:00:00 1940 UTC = Sun Sep 1 00:20:00 1940 GHST isdst=1 Africa/Accra Mon Dec 30 23:39:59 1940 UTC = Mon Dec 30 23:59:59 1940 GHST isdst=1 Africa/Accra Mon Dec 30 23:40:00 1940 UTC = Mon Dec 30 23:40:00 1940 GMT isdst=0 Africa/Accra Sun Aug 31 23:59:59 1941 UTC = Sun Aug 31 23:59:59 1941 GMT isdst=0 Africa/Accra Mon Sep 1 00:00:00 1941 UTC = Mon Sep 1 00:20:00 1941 GHST isdst=1 Africa/Accra Tue Dec 30 23:39:59 1941 UTC = Tue Dec 30 23:59:59 1941 GHST isdst=1 Africa/Accra Tue Dec 30 23:40:00 1941 UTC = Tue Dec 30 23:40:00 1941 GMT isdst=0 Africa/Accra Mon Aug 31 23:59:59 1942 UTC = Mon Aug 31 23:59:59 1942 GMT isdst=0 Africa/Accra Tue Sep 1 00:00:00 1942 UTC = Tue Sep 1 00:20:00 1942 GHST isdst=1 Africa/Accra Wed Dec 30 23:39:59 1942 UTC = Wed Dec 30 23:59:59 1942 GHST isdst=1 Africa/Accra Wed Dec 30 23:40:00 1942 UTC = Wed Dec 30 23:40:00 1942 GMT isdst=0 Africa/Accra Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 Africa/Accra Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 Africa/Tunis Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:55:13 1901 PMT isdst=0 Africa/Tunis Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:55:13 1901 PMT isdst=0 Africa/Tunis Fri Mar 10 23:50:38 1911 UTC = Fri Mar 10 23:59:59 1911 PMT isdst=0 Africa/Tunis Fri Mar 10 23:50:39 1911 UTC = Sat Mar 11 00:50:39 1911 CET isdst=0 Africa/Tunis Sat Apr 15 21:59:59 1939 UTC = Sat Apr 15 22:59:59 1939 CET isdst=0 Africa/Tunis Sat Apr 15 22:00:00 1939 UTC = Sun Apr 16 00:00:00 1939 CEST isdst=1 Africa/Tunis Sat Nov 18 21:59:59 1939 UTC = Sat Nov 18 23:59:59 1939 CEST isdst=1 Africa/Tunis Sat Nov 18 22:00:00 1939 UTC = Sat Nov 18 23:00:00 1939 CET isdst=0 Africa/Tunis Sun Feb 25 21:59:59 1940 UTC = Sun Feb 25 22:59:59 1940 CET isdst=0 Africa/Tunis Sun Feb 25 22:00:00 1940 UTC = Mon Feb 26 00:00:00 1940 CEST isdst=1 Africa/Tunis Sun Oct 5 21:59:59 1941 UTC = Sun Oct 5 23:59:59 1941 CEST isdst=1 Africa/Tunis Sun Oct 5 22:00:00 1941 UTC = Sun Oct 5 23:00:00 1941 CET isdst=0 Africa/Tunis Sun Mar 8 22:59:59 1942 UTC = Sun Mar 8 23:59:59 1942 CET isdst=0 Africa/Tunis Sun Mar 8 23:00:00 1942 UTC = Mon Mar 9 01:00:00 1942 CEST isdst=1 Africa/Tunis Mon Nov 2 00:59:59 1942 UTC = Mon Nov 2 02:59:59 1942 CEST isdst=1 Africa/Tunis Mon Nov 2 01:00:00 1942 UTC = Mon Nov 2 02:00:00 1942 CET isdst=0 Africa/Tunis Mon Mar 29 00:59:59 1943 UTC = Mon Mar 29 01:59:59 1943 CET isdst=0 Africa/Tunis Mon Mar 29 01:00:00 1943 UTC = Mon Mar 29 03:00:00 1943 CEST isdst=1 Africa/Tunis Fri Apr 16 23:59:59 1943 UTC = Sat Apr 17 01:59:59 1943 CEST isdst=1 Africa/Tunis Sat Apr 17 00:00:00 1943 UTC = Sat Apr 17 01:00:00 1943 CET isdst=0 Africa/Tunis Sun Apr 25 00:59:59 1943 UTC = Sun Apr 25 01:59:59 1943 CET isdst=0 Africa/Tunis Sun Apr 25 01:00:00 1943 UTC = Sun Apr 25 03:00:00 1943 CEST isdst=1 Africa/Tunis Sun Oct 3 23:59:59 1943 UTC = Mon Oct 4 01:59:59 1943 CEST isdst=1 Africa/Tunis Mon Oct 4 00:00:00 1943 UTC = Mon Oct 4 01:00:00 1943 CET isdst=0 Africa/Tunis Mon Apr 3 00:59:59 1944 UTC = Mon Apr 3 01:59:59 1944 CET isdst=0 Africa/Tunis Mon Apr 3 01:00:00 1944 UTC = Mon Apr 3 03:00:00 1944 CEST isdst=1 Africa/Tunis Sat Oct 7 21:59:59 1944 UTC = Sat Oct 7 23:59:59 1944 CEST isdst=1 Africa/Tunis Sat Oct 7 22:00:00 1944 UTC = Sat Oct 7 23:00:00 1944 CET isdst=0 Africa/Tunis Mon Apr 2 00:59:59 1945 UTC = Mon Apr 2 01:59:59 1945 CET isdst=0 Africa/Tunis Mon Apr 2 01:00:00 1945 UTC = Mon Apr 2 03:00:00 1945 CEST isdst=1 Africa/Tunis Sat Sep 15 21:59:59 1945 UTC = Sat Sep 15 23:59:59 1945 CEST isdst=1 Africa/Tunis Sat Sep 15 22:00:00 1945 UTC = Sat Sep 15 23:00:00 1945 CET isdst=0 Africa/Tunis Fri Apr 29 22:59:59 1977 UTC = Fri Apr 29 23:59:59 1977 CET isdst=0 Africa/Tunis Fri Apr 29 23:00:00 1977 UTC = Sat Apr 30 01:00:00 1977 CEST isdst=1 Africa/Tunis Fri Sep 23 22:59:59 1977 UTC = Sat Sep 24 00:59:59 1977 CEST isdst=1 Africa/Tunis Fri Sep 23 23:00:00 1977 UTC = Sat Sep 24 00:00:00 1977 CET isdst=0 Africa/Tunis Sun Apr 30 22:59:59 1978 UTC = Sun Apr 30 23:59:59 1978 CET isdst=0 Africa/Tunis Sun Apr 30 23:00:00 1978 UTC = Mon May 1 01:00:00 1978 CEST isdst=1 Africa/Tunis Sat Sep 30 22:59:59 1978 UTC = Sun Oct 1 00:59:59 1978 CEST isdst=1 Africa/Tunis Sat Sep 30 23:00:00 1978 UTC = Sun Oct 1 00:00:00 1978 CET isdst=0 Africa/Tunis Tue May 31 22:59:59 1988 UTC = Tue May 31 23:59:59 1988 CET isdst=0 Africa/Tunis Tue May 31 23:00:00 1988 UTC = Wed Jun 1 01:00:00 1988 CEST isdst=1 Africa/Tunis Sat Sep 24 22:59:59 1988 UTC = Sun Sep 25 00:59:59 1988 CEST isdst=1 Africa/Tunis Sat Sep 24 23:00:00 1988 UTC = Sun Sep 25 00:00:00 1988 CET isdst=0 Africa/Tunis Sat Mar 25 22:59:59 1989 UTC = Sat Mar 25 23:59:59 1989 CET isdst=0 Africa/Tunis Sat Mar 25 23:00:00 1989 UTC = Sun Mar 26 01:00:00 1989 CEST isdst=1 Africa/Tunis Sat Sep 23 22:59:59 1989 UTC = Sun Sep 24 00:59:59 1989 CEST isdst=1 Africa/Tunis Sat Sep 23 23:00:00 1989 UTC = Sun Sep 24 00:00:00 1989 CET isdst=0 Africa/Tunis Mon Apr 30 22:59:59 1990 UTC = Mon Apr 30 23:59:59 1990 CET isdst=0 Africa/Tunis Mon Apr 30 23:00:00 1990 UTC = Tue May 1 01:00:00 1990 CEST isdst=1 Africa/Tunis Sat Sep 29 22:59:59 1990 UTC = Sun Sep 30 00:59:59 1990 CEST isdst=1 Africa/Tunis Sat Sep 29 23:00:00 1990 UTC = Sun Sep 30 00:00:00 1990 CET isdst=0 Africa/Tunis Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 04:14:07 2038 CET isdst=0 Africa/Tunis Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 04:14:07 2038 CET isdst=0 flower$ exit script done on Thu Dec 14 16:07:23 2000

1 0

Expired Rules: How Should They Be Handled
by Dave Skinner Dec. 14, 2000

Dec. 14, 2000

I have written some software to reduce the "tzdata" files down to their current GMTOFF values with associated Rule usage. The software ends up acting as an integrity check on the database, i.e. it coughs up current expired Rule usage. The following Rules, which are current Rule in the indicated Zones, have all expired. How should/are these Zones handled if a user does a "setenv TZ " of one of them? Dave Skinner dave(a)nurh.jpl.nasa.gov ------ africa ------ Rule Ghana Zone Africa/Accra Rule SA Zone Africa/Johannesburg Rule SL Zone Africa/Freetown Rule Tunisia Zone Africa/Tunis ---- asia ---- Rule HK Zone Asia/Hong_Kong Rule Mongol Zone Asia/Hovd Zone Asia/Ulaanbaatar Rule Phil Zone Asia/Manila Rule PRC Zone Asia/Harbin Zone Asia/Shanghai Zone Asia/Chungking Zone Asia/Urumqi Zone Asia/Kashgar Zone Asia/Macao Rule ROK Zone Asia/Seoul Rule Taiwan Zone Asia/Taipei ----------- australasia ----------- Rule AQ Zone Australia/Brisbane Rule Aus Zone Australia/Darwin Rule Cook Zone Pacific/Rarotonga Rule Holiday Zone Australia/Lindeman Rule NC Zone Pacific/Noumea Rule Vanuatu Zone Pacific/Efate ------------ northamerica ------------ Rule Barb Zone America/Barbados Rule Belize Zone America/Belize Rule CR Zone America/Costa_Rica Rule Guat Zone America/Guatemala Rule Haiti Zone America/Port-au-Prince Rule Salv Zone America/El_Salvador Zone America/Tegucigalpa ------------ southamerica ------------ Rule CO Zone America/Bogota Rule Peru Zone America/Lima Rule Uruguay Zone America/Montevideo

1 0

Book on time
by alan＠allm-geodata.com Dec. 14, 2000

Dec. 14, 2000

I came across this book in my local bookshop. It may be of interest Clark, Blaise Time lord: Sir Sandford Fleming and the creation of standard time Wiedenfeld & Nicholson, 2000. Best wishes Alan Pritchard The GLOBAL GAZETTEER: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

1 0

Acre (Brazil) representation
by Jesper Nørgaard Dec. 11, 2000

Dec. 11, 2000

In the tz database we have had the Acre state of Brazil represented by the zone America/Porto_Acre for a long time back, however, this contradicts the general rule that the most populous city should be chosen for a given country, state, region, island etc., which also was used when determining that the city Atalaia do Norte should not be used as representative for East Amazonas, but instead the most populous city Eirunepé. According to the page http://www.ibge.gov.br/ibge/estatistica/populacao/contagem/accont96.shtm which mentions 22 cities of Acre, the most populous is by far Rio Branco, with 228,857 inhabitants. The argument in the tz database is that Rio Branco could not be used because there is a (ed: relatively unknown) Rio Branco in Uruguay. The validity of this argument seems a bit doubtful to me. It would be like saying "We can't make a time zone Europe/Paris because there is a Paris in Tennessee; let's make it Europe/Lyon". Who would be looking for Lyon? There is another reason for not choosing Rio Branco though, the state Roraima was previously called state Rio Branco. Supposing that Rio Branco is not chosen, then the next-most populated city of Acre is Cruzeiro do Sul with 56,705 inhabitants, or if you don't like underscores in abundance as in America/Cruzeiro_do_Sul, there would be Tarauacá as in America/Tarauaca which has 23,715 inhabitants. Porto Acre really comes long down the list with only 8,326 inhabitants. In conclusion I recommend to change America/Porto_Acre to America/Rio_Branco as first option, America/Cruzeiro_do_Sul as second option and America/Tarauaca as third option. Regards, Jesper Nørgaard Email: jnorgard(a)Prodigy.Net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT, Lisboa 27, 06600 Mexico, D.F. Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://cimmyt.cgiar.org Check out my Time Zone Converter: http://timezone50.homepage.com

1 0