[Fwd: [HACKERS] postgres and dates (year 2000? not!)]
| От | Thomas G. Lockhart |
|---|---|
| Тема | [Fwd: [HACKERS] postgres and dates (year 2000? not!)] |
| Дата | |
| Msg-id | 3698F46F.330B5775@alumni.caltech.edu обсуждение исходный текст |
| Список | pgsql-general |
> 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...
В списке pgsql-general по дате отправления: