On Mon, Jul 5, 2010 at 9:06 PM, Robert Elz <kre@munnari.oz.au> wrote:
The other representation is the zic output - that's simple, and in a format that is essentially never going to change in any incompatible way, as that's the format that software everywhere is reading to actually convert times between UTC and local time (both directions) - and because its format already allows for everything (being so simple).
Almost, but not quite. There are two things that I think are wrong with the zic output: - There's just a boolean indicating /whether/ we're observing some kind of advanced time (usually, but not necessarily, summer time, a.k.a., daylight saving time). There's no way to recover the standard offset from UTC from a single entry. You have to backtrack to the most recent entry for standard time and hope that it hasn't changed since then. - Multi-byte integers are aligned on arbitrary byte boundaries. This can be a hassle on systems that require stricter alignment. (This isn't a fundamental loss of data like the DST switch is, just a pain in the rear.) --Bill Seymour