Re: [GENERAL] leap day bug after 1901

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)

PostgreSQL checks for correct dates only for dates less than 1902 and
greater than 2037.

hygea=> select date '1900-04-31';
ERROR:  date_in: day must be limited to values 1 through 30 in
'1900-04-31'
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'
hygea=> select date '2039-04-31';
ERROR:  date_in: day must be limited to values 1 through 30 in
'2039-04-31'

I took a look at
src/backend/utils/adt/
        dt.c
        datetime.c
        nabstime.c

and I saw things like...


 if (tm->tm_year < 1901 || tm->tm_year > 2038

and

#define UTIME_MINYEAR (1901)
#define UTIME_MINMONTH (12)
#define UTIME_MINDAY (14)
#define UTIME_MAXYEAR (2038)
#define UTIME_MAXMONTH (01)
#define UTIME_MAXDAY (18)

Any body knows what does it mean ?

José