FW: Time Zone Data File Conventions

Alex LIVINGSTON alex at agsm.unsw.edu.au
Fri Oct 17 00:19:42 UTC 1997

John Cowan wrote:

>Wally Wedel wrote:
>> 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?
>In essence, yes.  For example, all DST transitions in the U.S. are
>defined by wallclock time: we transition at 2 AM defined by the
>prevailing time before the transition.  Thus the EST "Spring Ahead"
>transition occurs at 7 AM GMT, whereas the corresponding "Fall Back"
>transition occurs at 6 AM GMT.

I don't quite know which occurrences of the use of the terms "wall clock", "standard" and "GMT" Wally and John are thinking of. [Wally's question 1)b) is particularly eye-glazing to me without context.] Are they the ones purportedly, according to the "europe" file (and probably others), elucidated in the "africa" file, but which are not (as far as I can see). I quote:

  # See the `africa' file for time zone naming and abbreviation conventions.

I cannot find any explanation in the data files, nor in the "Theory" file, for a suffixed "u" or "s" on the time specified for a time transition (but perhaps I just haven't been thorough enough). Am I supposed to work it out by finding the piece of code that deals with it? What is the default interpretation (no suffixed alpha character)? I was also puzzled by the "%s" string that occurs in time-zone abbreviations until I asked a Unix/C-aware colleague. I realise this stuff is not meant for consumption by mere mortals, but would it not be a good idea to make it a bit more generally intelligible by the technocracy?

I'd now like include, slightly edited, part of a message I sent to Dave Skinner earlier this year which seems particularly relevant to this topic and which he encouraged me to post to this list.

I think it is misleading to ascribe a single time offset to places where the time kept varies during the year. The association with a particular time zone that that suggests is not necessarily warranted, and in many, if not most, cases, assuming that that offset applies is wrong *most* of the time! I am also at odds with calling either (any?) of the times kept at such locations "Standard" (or "standard"), as if the other(s) weren't. The association between "legal" or "wall-clock" time and local mean time (LMT) has, in my opinion, already essentially been lost in most places and might as well be forgotten about. I think that for places (zones) where more than one time is kept during the year *all* times (offsets) kept there should *always* be shown when giving time-zone information for that place (zone). And to distinguish between the different offsets, I would suggest using the terms "base time" (BT) and "advanced time" (AT). (The selection of which time to use as a base time is essentially arbitrary, and having a "base" time at all is only for convenience's sake.) If there were places which kept three different times during the year, the most "retarded" of these could be called "curtailed time" (CT) - contrived, I know, but the call of the alphabet was too tempting to resist; "base time" in such cases would, elegantly and as intuition would suggest, be the middle of the three.

Macintosh Support
Information Technology (IT)
Australian Graduate School of Management (AGSM)
The University of New South Wales (UNSW)
[Sydney]  NSW  2052

E-mail   : alex at agsm.unsw.edu.au; cit at agsm.unsw.edu.au (IT)
Facsimile: +61 2 9931-9349
Telephone: +61 2 9931-9264

More information about the tz mailing list