Question on abbreviations

[Robert Elz]

    Date:        Thu, 28 Sep 2006 00:29:52 -0700
    From:        Ken Pizzini <tz. at explicate.org>
    Message-ID:  <20060928072952.GA23423 at 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