- tz - lists.iana.org

tzdata format
by D. J. Bernstein Aug. 31, 1999

Aug. 31, 1999

Supposedly rule lines can occur in any order. What do the following lines mean? Rule Silly 1999 only - Sep 3 5:00 2:00 X Rule Silly 1999 only - Sep 3 6:00 1:00 Y Rule Silly 1999 only - Sep 3 8:00 -3:00 Z Starting from 0:00 +0000, do we increase to 5:00 +0000, then jump to 7:00 +0200, then increase to 8:00 +0200, then jump to 3:00 -0300, then increase to 6:00 -0300, then jump to 10:00 +0100, then increase? Or do we increase to 6:00 +0000, then jump to 7:00 +0100, then increase to 8:00 +0100, then jump to 4:00 -0300, then increase to 5:00 -0300, then jump to 10:00 +0200, then increase? Why aren't transition times labelled with the starting offset? Or, more simply, always specified in terms of standard time? I see that Tunisia one year had two transitions in the same month. Why are these part of the rule rather than the zone? Are there other examples of two transitions in the same month? Are there any DST systems that don't consist of two jumps in each applicable year, one jump early in the year, one jump late in the year? Are there any rule lines that cover multiple years without being part of such a pair? ---Dan

3 3

Re: time.h design issues
by Ulrich Drepper Aug. 31, 1999

Aug. 31, 1999

Paul Eggert <eggert(a)twinsun.com> writes: > I agree that my proposed API is still too complicated. When I get the > time I'll try to simplify it. Your code is a valuable resource in > this area: implementation experience counts for a lot in my book. Well, then I hope you suggest an implementation for a monotonic time implementation. Constraints are: The underlying OS will not notify each running program about a sudden clock change and itself does not provide a monotonic clock. In this situation the only thing you can count on are some hardware "clocks" the kernel does not (or cannot) influence. I think about things like the time stamp counters found on many modern processors. But: - they are only found on modern processors, and therefore a generic implementation isn't possible - even if they are available, they might be useless if, as in the case of the Alpha, the counter range is too small (just do the math: a 32 bit counter increment in each clock cycle on machines with, as seen two weeks ago, 1GHz clock speed). What I meant to say is think about the implementation before you propose something. It is certainly nice to have such a timer but it is very often not possible to implement it and for exactly this reason we have adjtime(). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

4 6

Tonga Daylight Savings Time
by Eric Ulevik Aug. 31, 1999

Aug. 31, 1999

On 19 August 1999, New Zealand TV's "ONE Network News" reported that Tonga will have DST from November to February, making it first into the new millenium. I don't have any details, unfortunately. Regards, Eric Ulevik eau(a)ozemail.com.au

1 0

FW: timezone improvements
by Olson, Arthur David (NCI) Aug. 30, 1999

Aug. 30, 1999

Robert E. Brown is not on the time zone mailing list; be sure to include Robert in any replies. --ado -----Original Message----- From: Robert E. Brown [SMTP:brownb@jany.gs.com] Sent: Thursday, August 26, 1999 1:24 PM To: tz(a)elsie.nci.nih.gov Subject: timezone improvements I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in: Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O. Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem. How can I get the capabilities I want integrated with the standard time zone library? By making it a part of the standard library, the chance increases that the code will be used, maintained, and completely debugged. We are willing to pay for the capabilities we want. Would Cygnus be a good source for this work? Do you have any other suggestions? Thanks very much. bob

6 16

Re: FW: timezone improvements
by Ulrich Drepper Aug. 27, 1999

Aug. 27, 1999

> How can I get the capabilities I want integrated with the standard time zone > library? By making it a part of the standard library, the chance increases > that the code will be used, maintained, and completely debugged. We are > willing to pay for the capabilities we want. Would Cygnus be a good source > for this work? Do you have any other suggestions? Thanks very much. I don't know exactly why you are referring to Cygnus. I guess because you associate my glibc work with my employer. And I also don't know which "standard library" you are referring to. glibc as used on Linux? You will most probably be out of luck trying to influence the commercial Unix vendors. If you know what interface you are looking for contact me and I can see whether it makes sense adding it to glibc. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

timezone improvements
by Robert E. Brown Aug. 26, 1999

Aug. 26, 1999

I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in: Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O. Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem. How can I get the capabilities I want integrated with the standard time zone library? By making it a part of the standard library, the chance increases that the code will be used, maintained, and completely debugged. We are willing to pay for the capabilities we want. Would Cygnus be a good source for this work? Do you have any other suggestions? Thanks very much. bob

1 0

Historical zone changes
by Lblumbbs＠aol.com Aug. 19, 1999

Aug. 19, 1999

In December 1941 I understand the time in Hawaii when it is on the hour in the Eastern Standard time zone was 30 minutes past the hour. Today ther minutes are the same. Can you tell me what the time zone difference between the Eastern Standard time zone and the time zone covering Hawaii was in 1941? Can you tell when (year and month) any changes to this time difference changed.

1 0

Re: tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Ulrich Drepper Aug. 17, 1999

Aug. 17, 1999

Ado, > The files > ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz > and > ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz Unfortunately the files are not readable in the moment: -r-------- 1 8800 0 92586 Aug 17 19:28 tzcode1999e.tar.gz -r-------- 1 8800 0 104493 Aug 17 19:28 tzdata1999e.tar.gz -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

The files ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz are now available. These files incorporate the changes circulated last week by Paul Eggert on the time zone mailing list, although the change to handling of DST-specifying time zone names has been commented out for now (search for "XXX" in "localtime.c" for details). These files also do not make any changes to the start of DST in Brazil. In addition to Paul's changes, there are updates to "Arts.htm" and cleanups of URLs. I imagine we'll see 1999f shortly with both changes in "localtime.c" and "southamerica"; folks can judge whether to await 1999f before downloading. --ado

1 0

FW: Changes in Brazil's daylight savings
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

Ricardo is not on the time zone list; be sure to include Ricardo in replies if appropriate. --ado -----Original Message----- From: Ricardo Reis [SMTP:rreis@ms.com] Sent: Tuesday, August 17, 1999 12:09 PM To: tz(a)elsie.nci.nih.gov Subject: Changes in Brazil's daylight savings Hi, just to inform that Brazil's daylight savings has been changed. Now it will start on Oct 03 1999 and will end on Feb 27 2000. I am attaching a southamerica file that includes this changes, but I am not experienced in this kind of updates, please rewrite it. Regards, Ricardo R. B. Reis <<southamerica.rreis>>

3 2