Re: [HACKERS] postgres and dates (year 2000? not!)
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] postgres and dates (year 2000? not!) |
Дата | |
Msg-id | 3698EC90.4FF5248D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | postgres and year 2000 (Massimo Dal Zotto <dz@cs.unitn.it>) |
Список | 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 valueswhen deciding whether a field is a year field. Assume *anything*longerthan 2 digits (if it isn't a special-case doy) is a valid year.This should fix the "Y1K" and "Y10K" problemspointed out by Massimo recently. Check usage of BC to require a positive-valued year; before just usedto flip the sign of the year without checking. Thisled to problemsnear 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 folksuse it...
В списке pgsql-hackers по дате отправления: