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@stanford.edu) <http://www.eyrie.org/~eagle/>