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. _______________ Alex LIVINGSTON Macintosh Support Information Technology (IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) [Sydney] NSW 2052 AUSTRALIA E-mail : alex@agsm.unsw.edu.au; cit@agsm.unsw.edu.au (IT) Facsimile: +61 2 9931-9349 Telephone: +61 2 9931-9264

From: Wally.Wedel@Sun.COM Sent: Wednesday, October 15, 1997 4:52 PM a) Does "wall clock" mean simply take the time as given applying no corrections? Yes; it means local time. E.g. in: Rule US 1967 max - Oct lastSun 2:00 0 S the `2:00' means the transition occurs at 02:00 local time. b) Does "standard" mean apply DST time shift to given time to find true time? Yes. E.g. in: Rule GB-Eire 1972 1980 - Oct Sun>=23 2:00s 0 GMT the `2:00s' means 02:00 local standard time. At those times there happens to be a 1-hour DST shift, so this happens to be equivalent to 03:00 local (daylight) time. c) Does "GMT" mean apply GMT offset to given time to get true time? Yes. E.g. in: Rule EU 1996 max - Oct lastSun 1:00u 0 - the `1:00u' means 01:00 UTC. E.g. for Europe/Helsinki, the change occurs at 04:00 local time, since they are 3 hours ahead of UTC in the summer. 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. This sounds correct, but to make sure, perhaps you could clarify your question with an example. 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. It'd be nice to have something like that. Have you looked at zone.tab and iso3166.tab, and how tzselect.ksh uses these auxiliary tables? Perhaps this could give you an idea about how to add info and/or generate HTML.