- tz - lists.iana.org

date formats
by Markus Kuhn July 23, 1998

July 23, 1998

Dave & Betty Fabian [SMTP:dfabian@sprynet.com] wrote: > Do you know where I can get a list of the local year-month-day orders > used in each country? For example, the U.S. uses month-day-year order. Local date format information is part of the locale data collection on <ftp://dkuug.dk/i18n/locales/> specified in POSIX locale format. More and more users and countries are moving towards the international standard date notation YYYY-MM-DD described on http://www.cl.cam.ac.uk/~mgk25/iso-time.html so you might consider using just this one for simplicity and prevention of confusion. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

Daylight saving time in selected countries
by Israel Schorr July 22, 1998

July 22, 1998

Dear Sirs, I am looking for the Daylight saving time guidelines (i.e. gneneral role for start date and end date) in selected countries, which I didn't manage to find elsewhere. The countries are: Armenia Belarus Jordan Kazakhstan Kyrgyzastan Latvia Lithuania Moldova Syria Ukraine I would appreciate any information. Thank You Israel Schorr

1 0

joining the tz@elsie.nci.nih.gov mailing list
by Israel Schorr July 22, 1998

July 22, 1998

Dear Sirs, We would highly appreciate if you could join us the the tz(a)elsie.nci.nih.gov mailing list. Thank you very much. Israel Schorr Our E-mail addresses ischorr(a)barakitc.co.il zsilbinger@ barakitc.co.il

1 0

tz problem with GMT leap seconds when the file "backward" is omitted
by Paul Eggert July 20, 1998

July 20, 1998

We discussed the following change as part of a proposed larger patch in late May when talking about the problems with sendmail 8.8.8 in Australia. The rest of the patch was done in a different way, but it seems to me that a fix is still needed for installations that want leap seconds, but also want to omit the links mentioned in the file "backward". Another possible fix would be to modify localtime.c so that it loads "Etc/GMT" rather than "GMT" to get the leap second info for GMT. =================================================================== RCS file: RCS/backward,v retrieving revision 1997.10 retrieving revision 1997.10.1.1 diff -u -r1997.10 -r1997.10.1.1 --- backward 1997/12/11 17:44:35 1997.10 +++ backward 1998/05/24 07:28:25 1997.10.1.1 @@ -38,7 +38,6 @@ Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB -Link Etc/GMT GMT Link Etc/GMT+0 GMT+0 Link Etc/GMT-0 GMT-0 Link Etc/GMT0 GMT0 =================================================================== RCS file: RCS/etcetera,v retrieving revision 1997.11 retrieving revision 1997.11.1.2 diff -u -r1997.11 -r1997.11.1.2 --- etcetera 1997/12/29 14:31:50 1997.11 +++ etcetera 1998/07/20 19:15:00 1997.11.1.2 @@ -10,6 +10,12 @@ Zone Etc/UTC 0 - UTC Zone Etc/UCT 0 - UCT +# The following link uses older naming conventions, +# but it belongs here, not in the file `backward', +# as functions like gmtime load the "GMT" file to handle leap seconds properly. +# We want this to work even on installations that omit the other older names. +Link Etc/GMT GMT + Link Etc/UTC Etc/Universal Link Etc/UTC Etc/Zulu

1 0

tzdata1998f.tar.gz
by ado July 20, 1998

July 20, 1998

The file ftp://elsie.nci.nih.gov/pub/tzdata1998f.tar.gz is now available; this updates the "leapseconds" file to include the newly- announced insertion at the end of 1998. --ado

1 0

leap second
by Denis.Excoffier＠ens.fr July 17, 1998

July 17, 1998

>From iers(a)hpvlbi.obspm.fr Fri Jul 17 15:37:46 1998 >From: iers(a)hpvlbi.obspm.fr Date: Fri, 17 Jul 1998 14:20:19 +0100 To: adresc1(a)hpvlbi.obspm.fr Subject: Bulletin C number 16 Content-Length: 2025 INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE BUREAU CENTRAL DE L'IERS 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, 17 July 1998 Bulletin C 16 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 1999 A positive leap second will be introduced at the end of December 1998. The sequence of dates of the UTC second markers will be: 1998 December 31, 23h 59m 59s 1998 December 31, 23h 59m 60s 1999 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1997 July 1, 0h UTC, to 1999 January 1, 0h UTC : UTC-TAI = - 31s from 1999 January 1, 0h UTC, until further notice : UTC-TAI = - 32s 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 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 Central Bureau of IERS

1 0

Bulletin C number 16
by iers＠hpvlbi.obspm.fr July 17, 1998

July 17, 1998

INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE BUREAU CENTRAL DE L'IERS 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, 17 July 1998 Bulletin C 16 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 1999 A positive leap second will be introduced at the end of December 1998. The sequence of dates of the UTC second markers will be: 1998 December 31, 23h 59m 59s 1998 December 31, 23h 59m 60s 1999 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1997 July 1, 0h UTC, to 1999 January 1, 0h UTC : UTC-TAI = - 31s from 1999 January 1, 0h UTC, until further notice : UTC-TAI = - 32s 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 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 Central Bureau of IERS

1 0

Web SSC (Swiss Society of Chronometry)
by ssc＠centredoc.ch July 17, 1998

July 17, 1998

Dear Sirs, We are pleased to let you know that the Swiss Society of Chronometry has set a new Internet site providing informations on their activities, namely the Congresses which they organize. We would be grateful if you would set in your own site a link with the following address: www.centredoc.ch/ssc Swiss Society of Chronometry (SSC) or Société Suisse de Chronométrie (SSC) In a little time we will have an English version of SSC service available at the same address. Thank you for your attention and best regards, B. Chapuis CENTREDOC Rue Jaquet-Droz 1 2007 Neuchâtel, Switzerland tel +41 32-720 51 31 fax +41 32-720 57 51 (e-mail ssc(a)centredoc.ch)

1 0

Re: Porting zoneinfo routines to Win32?
by guy＠netapp.com July 15, 1998

July 15, 1998

> Not that I know of... but I've considered it. The ideal situation would be > to take this database and put it under the Win32 APIs. Unfortunately, this > is not simple because the Win32 APIs don't understand that time zone rules > vary from year to year. Depends on the API. "FileTimeToSystemTime()" doesn't care, just as "localtime()" doesn't care, and "SystemTimeToFileTime()" doesn't care, just as "mktime()" doesn't care; however, "GetTimeZoneInformation()" *does* care - but, then, so does part of the SV time zone API - all you get from it is "timezone", "altzone", and "daylight". Basically, the fields of a "TIME_ZONE_INFORMATION" structure on Win32 correspond to SV variables roughly as: Bias (daylight? altzone : timezone) StandardName tzname[0] StandardDate not available StandardBias timezone DaylightName tzname[1] DaylightDate not available DaylightBias altzone "StandardDate" and "DaylightDate" are tricky, but you could probably set them to the rules for the most recent transitions, or for the next transitions, when "GetTimeZoneInformation()" is called. It might be some work to infer that a POSIX-style rule was in effect, letting you do a day-of-month version of "TIME_ZONE_INFORMATION"... ...but, if the Olson code is ever changed to handle times that don't expire in 2038, it *might* make sense to, instead of just recording transition dates/times, record things like from this date to that date, the rule is this POSIX-style rule; from the previous date to this date, the rule is this other POSIX-style rule; from the previous date to this date, the rule is that it changes on this date at this time; etc., as a compression scheme, so that you don't just store a set of transition times from Jan 1 1970 00:00:00 UTC to 2^63 seconds after that, or whatever. In effect, you'd store the "Rule" entries, rather than the results of running those rules repeatedly. With a scheme like that, coughing up POSIX-style rule information would be easier. It can still handle rules that change from year to year, but if the rules don't change every year, you can have a single entry cover multiple years.

2 1

Parsing Dates?
by Chris Sells July 13, 1998

July 13, 1998

Has anyone used the zoneinfo data to parse date strings into tm structures, e.g. "6/2/69 1:00pm CST" or "Jun 2 69 13:00 CST"? Chris Sells http://www.sellsbrothers.com

2 1