> Is there a reason for the restriction to one byte? Offhand I don't
> recall that we store TZ offsets on disk at all...
Ah, we don't. Sorry I wasn't clear. This is only for the lookup table we
use to interpret time zones on *input*. It is contained in
src/backend/utils/adt/datetime.c
And it ha
> Well, sheesh. Let's widen the byte field to int and store all the
> offsets in minutes, or even seconds.
It doesn't really matter, since the table is used only internally, and
only holds current accepted values for time zone offsets. The current
scheme works.
It might be useful to change the
Thomas Lockhart <[EMAIL PROTECTED]> 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 reaso
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Is there a reason for the restriction to one byte? Offhand I don't
>> recall that we store TZ offsets on disk at all...
> Ah, we don't. Sorry I wasn't clear. This is only for the lookup table we
> use to interpret time zones on *input*. It is contai
