Thomas Lockhart <[EMAIL PROTECTED]> writes:
> The fundamental problem (which of course can have a fundamental solution
> ;) is that a time zone database built with a 32-bit time_t will have
> time zone info through 2038 only (it is a binary file with 32-bit time
> fields -- almost certainly anyway).
I'm not sure that the time zone database tables store time_t's at all.
They certainly could be coded not to use 'em; but I do not know exactly
how various vendors have chosen to represent the data.
A random extract from the tzdata2002c files looks like:
Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:00
-6:00 US C%sT 1920
-6:00 Chicago C%sT 1936 Mar 1 2:00
-5:00 - EST 1936 Nov 15 2:00
-6:00 Chicago C%sT 1942
-6:00 US C%sT 1946
-6:00 Chicago C%sT 1967
-6:00 US C%sT
which might well be represented with separate y/m/d/h/m fields...
certainly we'd choose some such thing if we have to implement it
ourselves.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
