Re: Units for storage of internal time zone offsets

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> We have "always" stored our time zone offsets in a compressed
> divide-by-ten form to allow storage in a single byte. But there are a
> few time zones ending at a 45 minute boundary, which "minutes divided by
> 10" can not represent.

Is there a reason for the restriction to one byte? Offhand I don't
recall that we store TZ offsets on disk at all...

> But "minutes divided by 15" can represent this and afaik all other time
> zones in existance. I have patches which will do this (with changes done
> by a perl script so the math must be right ;). Can anyone think of a
> counter-example time zone which does not fall on a 15 minute boundary?

I dug through the zic timezone database, and it seems that as of current
practice, everyone is on hour, half-hour, or 15-minute GMT offsets, just
as you note. But twenty-minute offsets were in use as recently as 1979
in some places (Line Islands), and if you want to go back before about
1950 you'd better be prepared to handle very weird offsets indeed.

Given that we were just lecturing the glibc guys about access to
pre-1970 timezone info, it doesn't sit very well with me to adopt a
format that is designed only to support recent practice.

My preference would be to store the GMT offset to the nearest minute,
if we can afford the storage. What's the constraint exactly?

regards, tom lane