Date: Thu, 28 Sep 2006 00:29:52 -0700 From: Ken Pizzini <tz.@explicate.org> Message-ID: <20060928072952.GA23423@866863.msa.explicate.org> | I was just following the current convention: there are currently | 79 mentions of "saving time", 28 mentions of "savings time" and | zero mentions of "alternate time" in the tzcode+tzdata tree. | I probably should have said "summer time" though --- 123 mentions | of that term. What's in the tree is much less important for this than what's in the doc itself - that one should be somewhat consistent. In the data files we tend to get the locally appropriate "slang" name for the clock altering effect, which is fine (so it is daylight savings time in the US, and summer time in Aust - or was until US media influences brought "daylight savings" along with them). What is perhaps important here (for the doc) is that not all transitions are to/from whatever we call that effect - some are simply alterations from one zone offset to another (the standard time offset is altered). Referring to the transitions as all being to/from summer time (or savings time, or any other name like that) will lead to confusion when someone finds one of those transitions where a locality simply altered its definition of standard time. | I added it for emphasis. Emphasis is a useful thing; if one skimmed | too quickly over the first mention, the modifier here would give one | pause about "what is that `transition' adjective there for?" I actually disagree with the "emphasis is useful" - precision is useful, anything more than that degrades the result (for anything where technical accuracy is the objective - we're not talking literature here). Sure, very precise docs are dry, and hard to read, but anyone who does the work to read it carefully will be left in no doubt as to the meaning. Anyone who doesn't bother to read carefully doesn't really want to know anyway, and there's no reason for us to worry about them (eg: here, the people who raised the issues have obviously read the doc very carefully, and know exactly what is there). | Should be: maybe. But will it really be? In this very thread I've | seen the misinterpretation that this sentence is addressing crop up | after already explaining once about "transitions". You're assuming that your explanation was read (and read before the misinterpretation). That's not necessarily true. I'm certainly happy to have the doc become very clear on this point, which it clearly has not been, but I think once should be enough, I don't think harping on anything actually achieves much in the way of useful results. [the TYPE explanation] | I added it because I recall someone once being puzzled about its | purpose, Sure, I understand that, and don't object to it, its just that I am not sure that most of the readers of this doc care, and I suspect that those who do care already know, or would find out in other ways. | The places it is currently used is the "pacificnew" zone, which seems | a bit obscure, and the yearistype.sh script itself. In some ways it is a pity it was yanked from the rules for Australia/Adelaide It was used there in the early 1990's when summer time ended on the first Sunday in March in odd numbered years (and was consistent with most of the rest of Aust) but on the 3rd Sunday in March in even numbered years (and was inconsistent with everyone else). There we had a case where the TYPE specification was actually being used in a real production zone (unlike pacificnew). However, by the mid 1990's, summer time was extended (everywhere in Aust) to the end of March, so this even/odd year distinction was irrelevant. Then, once the limits were known, the transitions could be (and now are) handled by a sequence of "only" rules, rather than using the even/odd year rule. Since that means the yearistype script isn't needed to compile the zone file, everything gets simpler (some systems shipped zic, but not yearistype, which worked everywhere except for the australasia file). | While by the very nature of the beast, more folk will refer to this | document for the purpose of interpreting the tzdata files, I think that | the document should nevertheless also be suitable as stand-alone | documentation for those who compose rules. Because the use of a TYPE | other than "-" is so rare I felt that it would be useful to spell out | its rationale in this "primary documentation" of the file format. OK, but again (harping on ... and hence probably annoying both you and everyone else...) I'm not sure that there is a need for rationale in the specification. It simply needs to specify what happens, not why someone might want to use it (if for no other reason than that giving an example like that can stifle creativity - people come to believe that this feature is for a particular purpose, and never imagine the other ways it can be used). For example, the changes in Egypt/Syria/... recently may have been better handled by a "ramadan-at-timeshift" TYPE specifier, and some magic code in yearistype.sh to determine whether the year in question is the one that needs different summer time rules than normal. | My wording is bad: sure. Yes, as I said, I saw your update, and the "even better needed" part of that - I wasn't commenting upon the particular wording. | But I think you're misrepresenting the problem being addressed. No, I understand that. I just think that if we make it clear that the way to handle any time conversion (given an absolute time (incl date), find what UTC offset & name applied (or applies) to it for a particular zone) by saying "find the preceding transition, and the offset and name specified there apply" which I think is how we should make it very clear that the rules are just specifying transitions, and not time ranges - then we need some general statement about what to do when there is no previous transition. If we have that, it can include this case as well as part of the general (early time) handling methods. For this I don't think it needs to matter whether the previous transition is one caused by a ZONE or a RULE - it is just "the previous transition". Also note that it is perfectly possible to define a zone with absolutely no transitions, in fact, we have several already, consider these ... Zone Etc/GMT 0 - GMT Zone Etc/UTC 0 - UTC Zone Etc/UCT 0 - UCT The fact that the offset there is 0 is (almost) just a conincidence, it is perfectly acceptable to define a zone as Zone America/Eastern-Standard -5:00 - EST And since it is possible to use %s in a FORMAT, I could also do Zone America/Eastern-Standard -5:00 - E%sT but I'm not real sure what that one would mean (where does the %s value come from here?) We probably need to say that %s can only be used when the RULES/SAVE field actually specifies rules (not when it is '-' or an explicit adjustment). We should also probably do away with the "Alternatively, a slash (/) separates standard and daylight abbreviations." for the FORMAT as a particularly poor idea (fortunately, never used to my knowledge). (Do away as in from the code, as well as the doc, of course...) | With the sole exception of handling a variable-text part of a FORMAT, | a lack of *Rule* transitions preceding the first (or any other) *Zone* | transitions means "there are no transitions, so this is a no-op". | I guess we could emphasize that the SAVE offset from the GMTOFF would | be zero seconds in this case, but that seems excessive to me. It is a matter of how we specify how to handle the data - if we always say "look for the preceding transition", which is what I am suggesting, then we have to actually say what to do when there is none found - even if that is as simple as "zero seconds from the (first) gmtoff for the zone and the substitute for %s in a FORMAT is ..." | *shrug* If this were HTML I'd use <em>must</em>, not <strong>must</strong>, | as I just wanted to emphasise this requirement. A minor style point; I'll | defer to ADO's discretion of what (if any) font change to apply there. Minor style point perhaps (especially as half the time people read this stuff in effectively ascii anyway, where all of this is rendered in various obscure ways) - but my understanding is/was that italics are supposed to be used for quotations, latin words, other special terms, and stuff like that, not for emphasis - for emphasis one uses underlining or bold (or bigger) font, or even all capitals. I kind of suspect (unsupported by much in the way of evidence) that all this got confused in the days of typewriters, where there was no way to get italic font, so underlining got used instead, on the other hand, a kind of bold could be done by overstriking. Then when we went back to typesetting (or the modern equivalents) someone decided that anything which had been underlined should be set in italics - including where the underlining had been intended for emphasis, not because what was written was latin (eg...) or a quotation. Now we have a mess, where the conventions are largely gone, and it is hard to ascribe any meaning to what is presented, other than "that is different". Nevertheless, unless there's a very good reason, it makes sense to try and do things the right way. kre