Thread: Re: PostgreSQL + year 2000

Hi Gregor...

    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...

    Unix, in general, doesn't fall under the Y2K problem, since its
dates are represented in seconds since epoch...which hits its limit aroudn
the year 2039, and I elieve all our dates are represented as the full
year (1998), not the partial (98)...


 On Fri, 21 Aug 1998, Gregor Notten wrote:

> Hello Marc,
>
> I'm planning to start using PostgreSQL in the near future. But one thing
> I need to know:
>
>    Is PostgreSQL 'year 2000 compliant'?
>
> Can you give me an answer to this question? Thank you in advance.
>
> Regards,
> Gregor Notten
>

> 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