Thank you, and a brief note on time zone offsets

[Russ Allbery]

I've just spent a very enjoyable and interesting part of a couple of days
reading the full archives of the tz mailing list.  Thank you, all!  I now
know considerably more about a rather fascinating topic than I did before.
(And having the full archives going back fifteen years all available, in a
format that my mail reader can even thread, sort, and score for me, is
very nice; I'll have to bear that in mind for any mailing lists I may run
in the future.)

In partial thanks for all of the good information, here's a gotcha that I
don't believe has been mentioned on this mailing list previously.  There
has been some previous discussion about the preferred form of representing
time zone offsets; RFC 822 uses [+-]HHMM, while some other formats put a
colon between the hours and the minutes.  The previous discussion didn't
seem to turn up much reason for preferring one over the other, and some
general preference for leaving out the colon for a shorter format.

I became interested in this whole topic in the process of standardizing
INN's internal generation of Date headers.  When I started on that, I
discovered that someone who had been (re-)implementing support for
generation of Date headers in the local time zone rather than UTC had
taken the offset from UTC in seconds and, to convert to an offset, simply
divided by 36!

Thankfully, this never made it into a released version (and it's now
fixed), but the RFC 822 format, combined with the relative scarcity of
time zones whose offsets aren't even numbers of hours, actively encourages
this mistake.  Seconds offset from GMT divided by 36 and printed out as a
number is actually correct for hour offset time zones, but gives
e.g. -0250 instead of -0230 for other time zones, because rather than
HHMM, it's actually fractional hours multiplied by 100.

Had RFC 822 required the colon between hours and minutes, it would have
made it clear that they were two separate numbers and would probably have
prevented this mistake.  As always with standards, it's best if a cursory
inspection of the results suggests the right implementation, or at least
doesn't suggest a mistaken implementation, as a lot of code gets written
without actually referring to the real standard.  :/

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>