Re: Strange behavior with leap dates and centuries BC

Поиск
Список
Период
Сортировка
Искать
От
Bernd Helmle
Тема
Re: Strange behavior with leap dates and centuries BC
Дата
Msg-id
5DA9977D08F9A8407D83A128@imhotep.credativ.de
Ответ на
Список
Дерево обсуждения
Strange behavior with leap dates and centuries BC Bernd Helmle <mailings@oopsware.de>
Re: Strange behavior with leap dates and centuries BC Tom Lane <tgl@sss.pgh.pa.us>
Re: Strange behavior with leap dates and centuries BC Bernd Helmle <mailings@oopsware.de>
Re: Strange behavior with leap dates and centuries BC Tom Lane <tgl@sss.pgh.pa.us>
Re: Strange behavior with leap dates and centuries BC Bernd Helmle <mailings@oopsware.de>
Re: Strange behavior with leap dates and centuries BC Bruce Momjian <bruce@momjian.us>
--On Montag, Februar 25, 2008 12:00:05 -0500 Tom Lane  
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 по дате отправления
От: Gregory Stark
Дата:
От: Peter Eisentraut
Дата:
FAQ