Re: [HACKERS] Date/time types: big change

> But conversion timestam to 'tm' struct is not Y2038 ready
> (POSIX 'tm' limitation?):
> to_char
> ---------------
> 10:57:47 2038
> (1 row)
> Or am I something leave out?

No, that is the expected behavior. In most of the world (certainly in
the US), time zones and daylight savings time were both very nebulous
things until around the turn of the century. I recall reading that in
the US building the continental railroads in the 1860's provoked
thinking about standardizing time zone.

There are also minor changes in time zone and DST behavior in recent
history; in the US we had a year or two in the 1970's which ran DST
year round due to the oil shortage.

So, since the actual time zone behavior for years past 2038 is
uncertain, and since the Unix time support routines don't support
anything past 2038 anyway, I omit time zone calculations after
2038-01-18 and before 1901-12-14. Everything is carried as equivalent
to GMT, but no time zone adjustment is carried out.

btw, there *may* be some edge effects which are, um, unexpected; e.g.
having a time zone adjustment as you enter a date w/o an explicit tz
into the database, to which the same adjustment is *not* applied as
the date is read back out. Feel free to test it out...

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California