On Tue, Jan 09, 2001 at 05:05:34PM +0000, Thomas Lockhart wrote:
> > What I do not understand is, that I thought a time in december cannot be
> > affected by such math because it is clearly not in the daylight savings
> > months of the year ? Also I thought that you recognize daylight savings
> > time by the PDT instead of PST, and PostgreSQL shows a result with PST
> > as I would have expected, but one hour off.
>
> By the time the math is actually done, the date is in GMT. So the issue
> is: how does one assign the time zone for the result?
> ...
> 3) Some platforms do not do the right thing wrt time zones for dates
> before 1970. For example, the USA had some weird time zones during WWII,
> and this is reflected in Sun's time zone database but not quite as
> accurately in the open source zinc package that Linux and others use.
> And other platforms (such as AIX?) prefer to do it themselves and get it
> wrong altogether.
Indeed, Unix time_t is not required to represent any time before 1970,
so it may be that on AIX the time zone computation is treating it as
a very large unsigned (therefore positive) value, coming up with a time
in the summer of (perhaps) 2098, and adjusting the time accordingly;
then feeding the time to a different conversion that treats negative
time_t values as really negative.
Of course, it is a grievous error to use Unix time_t to represent
real-world dates (e.g. birthdates). Didn't Y2K teach us anything?
ISTM the correct response is to remove test cases from the regression
suite that refer to times before 1970 and after 2038, if they involve
a time_t representation.
Nathan Myers
ncm@zembu.com