Question on abbreviations

Robert Elz kre at munnari.OZ.AU
Thu Sep 28 06:22:09 UTC 2006

    Date:        Wed, 27 Sep 2006 20:34:10 -0700
    From:        Ken Pizzini <tz. at>
    Message-ID:  <20060928033410.GA22927 at>

  | Okay, here's what I came up with --- not so much rewording as
  | adding clarifications:

I'm not sure  that is the best approach - we can keep on adding more and
more clarifications, and that just means more and more text to confuse people.

What's really needed is to be as precise as possible, as briefly as
possible, so there's less room left for confusion or ambiguity.

  | And for ADO, here is the corresponding diff to the zic.8 page:

I'm going to comment on these, as it's much easier to see what
changes you're proposing this way ...

I will, of course, omit most of the diff, leaving just the
specific changes of concern.

  | -Input lines are made up of fields.
  | +Input lines are made up of
  | +.B specified
  | +fields.

I doubt that adding that word by itself will accomplish anything, all
that leads to is "what are specified fields ?"

  | +Each rule specifies one or more
  | +.I transitions
  | +between standard and saving time.

This one I think is the crucial sentence to add.  In fact, perhaps
even another sentence:

	The offset from UTC that applies at any particular time can be
	obtained by finding the nearest preceding transition.

And even, perhaps, something about what happens before the first

However, I'm not sure we should say (anywhere) "saving time",
as "saving" (with respect to time, or for that matter, daylight)
has nothing at all to do with what is happening (saving energy
perhaps).   It is probably best just to call them "standard"
and "alternate" time offsets (or something like that).

  | -Gives the first year in which the rule applies.
  | +Gives the first year in which the transition rule applies.

Adding that word helps nothing, the earlier addition already made clear
that the rules are transition rules.

  | +Note that the
  | +.I offset
  | +that the rule transitions will continue on until the next
  | +transition occurs,
  | +no matter how far in the future of the
  | +.B FROM
  | +or
  | +.B TO
  | +years that may be.

(That's the one you sent alternative (better) wording for in a later message).

I don't think that's needed at all - simply saying (along with the
definition of the rules as transitions) that the offset at time X is
that given by the most recent transition before (or at) X should be

  | +This might be used, for example, to have a rule which applies only in
  | +leap years.

That's OK, I guess, but I'm not sure it is needed.   As long as the
field isn't used, no-one much cares what it might be used for (except
the very few people who write data for these files and even then only in
unusual cases - most people are concerned with extracting the data).
Where the field is used, its purpose is generally both well commented, and
really obvious.

  | +.IP
  | +Note that, as a special case, references to a rule's
  | +.B LETTER/S
  | +field
  | +(through a %s in a zone line's
  | +.B FORMAT
  | +field)
  | +for a date which predates the oldest date specified in a given rule
  | +will be assigned the
  | +.q "variable part"
  | +specified by the oldest
  | +.I standard time
  | +(i.e., with a
  | +.B SAVE
  | +value of zero)
  | +transition specified for the named rule.

It may be better to have something in general which specifies how to
process data before the first transition (and for when there are no
transitions at all) - both for the zone name abbreviation, and for the
offset to use, as in general we are (or should) be telling people
normally to locate the preceding transition - we do need to say what
to do when there is no preceding transition.

In there, the text above would explain how the abbreviation is derived
(when %s is used anyway) but it wouldn't need the "Note that as a special case"
part, as the whole section would be something of a special case.

  | -It is specified as a year, a month, a day, and a time of day.
  | +This field, which is logically a single field in the sense of the
  | +high-level description, consists of whitespace separated subfields
  | +consisting of a year, a month, a day, and a time of day.

I think this is the wrong way to explain this - better to explain that
the final field contains whatever data is left on the input line, white
space included, after all previous fields have been assigned values.

Then it wiil be fine to say that the until field contains year month day & time.

  | -The next line must be a
  | +The next line
  | +.I must
  | +be a

Putting "must" in italics is just wrong - if it needed emphasising at
all (which I don't think it does), it should be bold, not italics.
Just leave that one the way it was.


More information about the tz mailing list