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