August 1999 - tz - lists.iana.org

FW: DST changes in australasia due to 2000 Olympics
by Olson, Arthur David (NCI) 02 Sep '99

02 Sep '99

Please include Carol (who is not on the time zone mailing list) in any replies. --ado -----Original Message----- From: cfields(a)kapaa.eng.sun.com [SMTP:cfields@kapaa.eng.sun.com] Sent: Wednesday, August 11, 1999 2:55 PM To: tz(a)elsie.nci.nih.gov Subject: DST changes in australasia due to 2000 Olympics I am fixing a zoneinfo bug in Solaris. One of our customers has pointed out that daylight saving should be fixed for NSW due to the Sydney Olympics. The NSW government web site, http://dir.gis.nsw.gov.au/cgi-bin/genobject/document/other/daylightsaving/t… ITWr0 shows the following: -------- Daylight saving will commence on the last Sunday in October at 2:00am EST and continue until the last Sunday in March at 3:00am EDST. 1998 - 1999 Start: Sunday October 25, 1998 Finish: Sunday March 28, 1999 1999 - 2000 Start: Sunday October 31, 1999 Finish: Sunday March 26, 2000 2000 - 2001 Start: Sunday August 27, 2000 Finish: Sunday March 25, 2001 (Starting at 2.00am and Finishing at 2.00am) -------- In tzdata1999d (australasia 7.46), Rule AV and AN show the daylight saving change on Aug 26 in 2000. Would the following fix the correct set of timezones that are adopting this change? % diff australasia australasia.fix 116c116 < Rule AV 2000 only - Aug 26 2:00s 1:00 - --- > Rule AV 2000 only - Aug lastSun 2:00s 1:00 - 136c136 < Rule AN 2000 only - Aug 26 2:00s 1:00 - --- > Rule AN 2000 only - Aug lastSun 2:00s 1:00 - Carol Fields carol.fields(a)eng.sun.com

3 2

C9X and Time
by Clive D.W. Feather 02 Sep '99

02 Sep '99

Sorry it's taken me so long to get round to this. The last WG14 meeting agreed, in principle, that a work item could be started on new time facilities for C. The result of the work item would be a Normative Amendment that would add these facilities to the language. There was no objection to the proposal that the facilities be designed "from the ground up"; they do not have to be based on the existing <time.h> functions. Where do we want to go from here ? -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 20 8371 1037 Demon Internet Ltd. | WWW: http://www.davros.org | Mobile: +44 973 377646

6 8

tzdata format
by D. J. Bernstein 31 Aug '99

31 Aug '99

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 31 Aug '99

31 Aug '99

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 30 Aug '99

30 Aug '99

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) 30 Aug '99

30 Aug '99

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 27 Aug '99

27 Aug '99

> 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 26 Aug '99

26 Aug '99

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 19 Aug '99

19 Aug '99

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 17 Aug '99

17 Aug '99

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