Re: [GENERAL] leap day bug after 1901
От | José Soares |
---|---|
Тема | Re: [GENERAL] leap day bug after 1901 |
Дата | |
Msg-id | 3713496F.2895F6AF@sferacarta.com обсуждение исходный текст |
Ответ на | leap day bug after 1901 (José Soares <jose@sferacarta.com>) |
Список | pgsql-general |
José Soares ha scritto: > Hi all, > > Seems that PostgreSQL checks for leap day only before 1902. > > prova=> select date '0001-02-29'; > ERROR: date_in: day must be limited to values 1 through 28 in > '0001-02-29' > > prova=> select date '1701-02-29'; > ERROR: date_in: day must be limited to values 1 through 28 in > '1701-02-29' > > prova=> select date '1901-02-29'; > ERROR: date_in: day must be limited to values 1 through 28 in > '1901-02-29' > > prova=> select date '1902-02-29'; > ?column? > ---------- > 1902-03-01 > (1 row) > > José Any body knows why PostgreSQL checks for date validity only for dates less than 1902 and greater than 2037 ? hygea=> select date '1901-04-31'; ERROR: date_in: day must be limited to values 1 through 30 in '1901-04-31' hygea=> select date '1902-04-31'; ?column? ---------- 1902-05-01 (1 row) hygea=> select date '2037-04-31'; ?column? ---------- 2037-05-01 (1 row) hygea=> select date '2038-04-31'; ERROR: date_in: day must be limited to values 1 through 30 in '2038-04-31' I looked at .../src/backend/utils/adt/ and I saw many references to 1901-2038 in files dt.c, datetime.c and nabstime.c. Any body knows what does it mean ? #define UTIME_MINYEAR (1901) #define UTIME_MAXYEAR (2038) #define MIN_DAYNUM -24856 /* December 13, 1901 */ #define MAX_DAYNUM 24854 /* January 18, 2038 */ /* validate, before going out of range on some members */ if (tm->tm_year < 1901 || tm->tm_year > 2038 Jose'
В списке pgsql-general по дате отправления: