- tz - lists.iana.org

`AET' vs `GST' for time in United Arab Emirates
by Paul Eggert Nov. 12, 1997

Nov. 12, 1997

In <news:641quc$182@t1.emirates.net.ae> (1997-11-08), framness(a)EMIRATES.NET.AE (Mark Framness) writes that he uses AET as a string that he made up for ``Arab Emirates Time''. Currently the tz database at ftp://elsie.nci.nih.gov/pub/ uses `GST' for the Persian Gulf states, but that was an abbreviation that I invented from whole cloth, and this news posting suggests that the tz database should use ISO country codes instead for the Persian Gulf area. Similarly for `AST/ADT' for Arabia Standard/Daylight Time. Comments?

1 0

Re: 32-bit 2038 issue
by Joel.Tornatore＠Eng.Sun.COM Nov. 11, 1997

Nov. 11, 1997

changing time_t to an unsigned int would give another 68 years without any of the size/performance problems mentioned in Tom's email. joel ## From tomp(a)zk3.dec.com Tue Nov 11 12:40:27 1997 ## Old-Return-Path: <tomp(a)zk3.dec.com> ## To: tz(a)elsie.nci.nih.gov ## Cc: Tom Peterson <tomp(a)zk3.dec.com>, simons(a)zk3.dec.com, dlong(a)zk3.dec.com ## Subject: 32-bit 2038 issue ## X-Mts: smtp ## ## ## Has anyone considered what to do about time zone files and the 32-bit 2038 ## issue? This comment from zic.c sums up the problem: ## ## > /* ## > ** The tz file format currently allows at most 32-bit quantities. ## > ** This restriction should be removed before signed 32-bit values ## > ** wrap around in 2038, but unfortunately this will require a ## > ** change to the tz file format. ## > */ ## ## With Y2K bringing attention to time-related problems, there's an increasing ## awareness/concern about the 2038 issue as well. People know it's not just a ## system clock setting issue. The limitations affect projected dates used by ## applications as well. Problems are already cropping up where financial ## institutions can't generate amortization data for 40, 50, etc year loans and ## the like. I expect there are other practical examples as well. ## ## As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit ## time_t's. While this certainly eliminates the 2038 limit, it also creates a ## problem for time zone data files. A time zone file filled with data spanning ## 64-bits of seconds-based time would be huge, not to mention the performance ## problems of accessing it. Some ideas for addressing this problem are: ## ## 1) Expand the date/time boundaries for time zone files to a specific range. ## This would have to balance file size vs anticipated application needs. ## Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? ## Regardless of the range set, this approach only delays the problem. ## ## 2) Find some way to mimic what the zic compiler does at run-time. This might ## involve generating some kind of algorithmic data for each time zone which can ## be used to calculate future transition times, etc on-the-fly. I'm not sure ## this is possible or practical given the varied complexity of time zone rules. ## ## 3) Other ideas??? ## ## Also, with 64-bit time_t's, the tm struct becomes the limiting factor. ## Boundary checks now become an issue for localtime()/gmtime() instead of ## mktime(). This is a problem for standards at a mininum. While mktime() has ## the (somewhat ambiguous) -1 return value for non-representable times, no such ## provision is defined for localtime()/gmtime(). ## ## Any ideas or precedent for addressing this issue? ## ## thanks, ## - Tom ## ## ===================================================================== ## Tom Peterson | DIGITAL UNIX Development Environment ## Digital Equipment Corporation | Phone: (603) 884-7550 ## 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 ## Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com ## ## ##

2 1

Re: 32-bit 2038 issue
by Robert Elz Nov. 11, 1997

Nov. 11, 1997

Date: Tue, 11 Nov 1997 13:50:33 -0800 From: Joel.Tornatore(a)Eng.Sun.COM (Joel Tornatore) Message-ID: <199711112150.NAA26831(a)gap.eng.sun.com> | changing time_t to an unsigned int would give another | 68 years without any of the size/performance problems | mentioned in Tom's email. I made that change back in pre 4.2 bsd days. It turned out that it broke too much - most notably, programs that like to print ctime(0) (and there I mean the time_t with a value of 0, I know ctime really takes a pointed to a time_t, and ctime(0) would be a null pointer). The standard behaviour, anywhere west of Greenwich, was to not print Dec 31 1969 in that case, but some time way into the future, which was not at all what anyone expected. So, before 4.2 was actually released, time_t went back signed again. It was all this that caused some of the time functions able to adapt and work whether time_t turns out to be signed or not. kre

1 0

32-bit 2038 issue
by Tom Peterson Nov. 11, 1997

Nov. 11, 1997

Has anyone considered what to do about time zone files and the 32-bit 2038 issue? This comment from zic.c sums up the problem: > /* > ** The tz file format currently allows at most 32-bit quantities. > ** This restriction should be removed before signed 32-bit values > ** wrap around in 2038, but unfortunately this will require a > ** change to the tz file format. > */ With Y2K bringing attention to time-related problems, there's an increasing awareness/concern about the 2038 issue as well. People know it's not just a system clock setting issue. The limitations affect projected dates used by applications as well. Problems are already cropping up where financial institutions can't generate amortization data for 40, 50, etc year loans and the like. I expect there are other practical examples as well. As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit time_t's. While this certainly eliminates the 2038 limit, it also creates a problem for time zone data files. A time zone file filled with data spanning 64-bits of seconds-based time would be huge, not to mention the performance problems of accessing it. Some ideas for addressing this problem are: 1) Expand the date/time boundaries for time zone files to a specific range. This would have to balance file size vs anticipated application needs. Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? Regardless of the range set, this approach only delays the problem. 2) Find some way to mimic what the zic compiler does at run-time. This might involve generating some kind of algorithmic data for each time zone which can be used to calculate future transition times, etc on-the-fly. I'm not sure this is possible or practical given the varied complexity of time zone rules. 3) Other ideas??? Also, with 64-bit time_t's, the tm struct becomes the limiting factor. Boundary checks now become an issue for localtime()/gmtime() instead of mktime(). This is a problem for standards at a mininum. While mktime() has the (somewhat ambiguous) -1 return value for non-representable times, no such provision is defined for localtime()/gmtime(). Any ideas or precedent for addressing this issue? thanks, - Tom ===================================================================== Tom Peterson | DIGITAL UNIX Development Environment Digital Equipment Corporation | Phone: (603) 884-7550 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com

2 1

request!
by Gatsometer Nov. 11, 1997

Nov. 11, 1997

Hello everyone, I am Peter Smit and working for Gatsometer Holland in R&D. Our equipment for traffic control is exported all over the world. I am looking for some data base or algorithm that produces GMT offset or TZ name if longitude and latitude are input from GPS. Perhaps you know someone or an institute that can help. I have already take a look at ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz and found there the file zone.tab. Thanks for your response. Regards, Peter Smit

1 0

Re: Time stamp(s)
by ncm＠cantrip.org Nov. 3, 1997

Nov. 3, 1997

Paul Eggert <eggert(a)twinsun.com> wrote: > From: "Olson, Arthur David" <OLSONA(a)dc37a.nci.nih.gov> > > my guess is that the thing to do is put at the start of the file a > count of the number of bytes worth of stamp that appear, then put > the stamp information itself at the end of the file. > > How would this work with the Unix `file' command? Mr. Eggert's posting seems to confuse two independent improvements: a file magic number and a set of validity timestamps. Of course any "record offset" for the timestamps would come after the magic number. I agree with Mr. Olson that it would be better not to use up all the remaining uncommitted bytes in the record for timestamps, and that placing the offset to such a record elsewhere in the file would be better. Nathan

1 0

Time stamp(s)
by Olson, Arthur David Nov. 1, 1997

Nov. 1, 1997

Whatever number of stamps end up in the file, my guess is that the thing to do is put at the start of the file a count of the number of bytes worth of stamp that appear, then put the stamp information itself at the end of the file. This minimizes the encroachment on the twenty remaining bytes of "reserved for future use" space; it also would allow us to have longish, easy-for-humans-to-read stamp information (either in addition to or instead of shorter, easy-for-computers-to-process information). My sense is that one stamp might be sufficient. A client picking up time zone information from multiple sources would use the one with the largest stamp. The stamp might be automatically generated as a function of the maximum "until" time appearing on a "Zone" line for the zone in question and the maximum "from" and "to" years appearing on a "Rule" line for the zone in question. Doing this would eliminate the need for separate maintenance of information from which to generate stamps; it would also avoid adding information to the zic input files that old versions of zic would not be able to handle. The down side would be that if we learned of a correction to zone information that only affected past times, we wouldn't get an *automatic* update of the stamp for the zone. Comments? --ado

2 1

Proposed DST change for Sydney Olympics
by Eric Ulevik Oct. 26, 1997

Oct. 26, 1997

SOCOG (the Sydney Organizing Commitee for the Olympic Games) have requested that daylight savings time start early in 2000, to make things easier when running the games. The proposed start date is 27 August 2000. This would mean Sydney having eight months of daylight savings time. Apparently the NSW Government is looking favourably on this proposal. Regards, Eric Ulevik Reference: Sunday Telegraph, 26 October 1997, page 26

1 0

News from the UK
by peter＠aldie.co.uk Oct. 25, 1997

Oct. 25, 1997

The Independent (one of the quality broadsheet papers over here) has a piece today (25 Oct) about the clock change tomorrow morning. It can be found at http://www.independent.co.uk/stories/A2510709.html. The short summary: John Butterfill won't be having another go at changing the law. He doesn't know of any other MP who will try. The Home Office say the government has no plans to legislate either. The only other recent thing of relevence I have seen is that a tiny footnote in the White Paper on Scottish Devolution said that `the regulation of time zones' was one of the things that would be reserved to Westminster and wouldn't be devolved. The White Paper is at http://www.scottish-devolution.org.uk/white%20paper/papercon.htm with the footnote being in Chapter 3. Peter Ilieve peter(a)aldie.co.uk

1 0

FW: Time Zone Data File Conventions
by Olson, Arthur David Oct. 17, 1997

Oct. 17, 1997

(Note that wally.wedel(a)central.sun.com is not on the time zone mailing list; be sure that a copy of any reply gets sent that way. --ado.) ---------- From: Waldo (Wally) Wedel [Sun Professional Services JDC][SMTP:wally.wedel@Central.Sun.COM] Sent: Wednesday, October 15, 1997 4:52 PM To: tz(a)elsie.nci.nih.gov Subject: Time Zone Data File Conventions Gentlemen: I am just finishing up implementing some general time zone classes in Java. I parse your data files and build time zone classes from them. Consequently, I have a few questions. 1) You use the concepts of "wall clock", "standard", and "GMT" time in specifying transition times. I'd like to verify just what these mean. a) Does "wall clock" mean simply take the time as given applying no corrections? b) Does "standard" mean apply DST time shift to given time to find true time? c) Does "GMT" mean apply GMT offset to given time to get true time? 2) Is the convention for rule naming that when searching for the applicable rule, one looks for a rule with the specified name covering the specified date? I assume that failure to find a rule implies no time shift. 3) The comments in the data files contain quite important information about the actual coded information. Have you considered converting them to HTML to get them better tagged? I'm particularly interested in tagging some kind of a long name usable in reports and like. I've been trying to figure out how to preserve them in an OODB so that they are properly associated with the data they describe. Thanks for any help you can provide. -- Wally Wedel Wally.Wedel(a)sun.com SunService Division (303) 804-3073 Java Design Center Fax: (303) 290-1696 5251 S DTC Parkway Englewood, CO 80111-2700

5 5