Re: [HACKERS] postgres and dates (year 2000? not!)

Thomas Lockhart <lockhart@alumni.caltech.edu>

From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
To: Massimo Dal Zotto <dz@cs.unitn.it>
Cc: PostgreSQL Hackers <hackers@postgreSQL.org>, announce@postgreSQL.org, general@postgreSQL.org
Date: 1999-01-10T18:08:16Z
Lists: pgsql-hackers
> it seems that the year handling in pgsql dates is not very consistent:
> The problem I see is that the same number is converted to a different 
> year depending on the number of digits and the number itself.

I've posted a patch intended for v6.4 and v6.4.2 at
  ftp://postgresql.org/pub/patches/dt.c.patch

which addresses some date interpretation problems, mostly for dates
containing leading zeros and/or an odd number of digits (I'm referring
to this as the "Y1K problem" :). It also fixes problems with two-digit
years for "concatenated dates" like "990110" and adds a "yydoy" 5 digit
concatenated date, like "99010".

I'll claim that none of these problems or fixes were related directly to
a "Y2K" problem, since it didn't work in "Y1900" either :/

cvs commit notes are included below. Let me know if there are any
problems.

                       - Tom

Be more careful to check input string lengths as well as values
 when deciding whether a field is a year field. Assume *anything* longer
 than 2 digits (if it isn't a special-case doy) is a valid year.
 This should fix the "Y1K" and "Y10K" problems pointed out by Massimo 
 recently.
Check usage of BC to require a positive-valued year; before just used
 to flip the sign of the year without checking. This led to problems
 near year zero.
Allow a 5 digit "concatenated date" of 2 digit year plus day of year.
Do 2->4 digit year correction for 6 and 5 digit "concatenated dates".
 Somehow forgot this originally. Guess not many folks use it...