> I believe we are compliant, up to at least the year 2039, when
> Unix has its "problems". Thomas would be better at answering this,
> though, as he knows the 'date/time' code the best...
The date/time types are completely system-independent, and have no
knowledge of Y2K (other than one type using Jan 1, 2000 as "time zero").
The date/time mathematics are based on astonomical algorithms which are
good from 4013BC to far into the future. All date/time types do use the
system to obtain "time now", so if your underlying system breaks then
this will too. I'm not aware of any Y2K problems in my underlying OS
(Linux) and I suspect other Unices will be similarly happy.
Perhaps some old PC hardware systems have Y2K problems which would
translate into Unix boot problems, but I don't know, just wondering.
Anyway, there isn't anything inside Postgres which would contribute to
the most glaring Y2K problems, like years stored with only two digits.
There is some code which tries to "do the right thing" if given a
two-digit year as _input_; it assumes any two digit year smaller than 70
is actually after 2000:
postgres=> select datetime '98-01-01'
postgres-> union select '80-01-01'
postgres-> union select '70-01-01'
postgres-> union select '60-01-01';
----------------------------
Thu Jan 01 00:00:00 1970 GMT
Tue Jan 01 00:00:00 1980 GMT
Thu Jan 01 00:00:00 1998 GMT
Thu Jan 01 00:00:00 2060
(4 rows)
- Tom
