Re: Strange behavior with leap dates and centuries BC - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: Strange behavior with leap dates and centuries BC
Date
Msg-id 5DA9977D08F9A8407D83A128@imhotep.credativ.de
Whole thread Raw
In response to Re: Strange behavior with leap dates and centuries BC  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Strange behavior with leap dates and centuries BC  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
--On Montag, Februar 25, 2008 12:00:05 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> regression=# select '0001-02-28 BC'::date + 1;
>    ?column?
> ---------------
>  0001-02-29 BC
> (1 row)
>
> regression=# select '0002-02-28 BC'::date + 1;
>    ?column?
> ---------------
>  0002-03-01 BC
> (1 row)

I stepped through the code in datetime.c and it seems the culprit here is 
DecodeDate(). It get's the date string from DecodeDateTime(), but without 
the 'BC' century notation. However, it then performs the following check
/* there is no year zero in AD/BC notation; i.e. "1 BC" == year 0 */if (bc){    if (tm->tm_year > 0)        tm->tm_year
=-(tm->tm_year - 1);    else        ereport(ERROR,                (errcode(ERRCODE_INVALID_DATETIME_FORMAT),
    errmsg("inconsistent use of year %04d and \"BC\"",                        tm->tm_year)));}
 

bc never becames true during parsing and the final check for the leap date 
fails:
/* We don't want to hint about DateStyle for Feb 29 */if (tm->tm_mday > day_tab[isleap(tm->tm_year)][tm->tm_mon - 1]){
 return DTERR_FIELD_OVERFLOW;}
 

Maybe that helps a little bit.

--  Thanks
                   Bernd


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Questions about indexes with text_pattern_ops
Next
From: Peter Eisentraut
Date:
Subject: Re: build environment: a different makefile