Skip site navigation (1) Skip section navigation (2)

Re: Strange behavior with leap dates and centuries BC

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Strange behavior with leap dates and centuries BC
Date: 2008-02-25 18:08:36
Message-ID: 5DA9977D08F9A8407D83A128@imhotep.credativ.de (view raw or flat)
Thread:
Lists: pgsql-hackers
--On Montag, Februar 25, 2008 12:00:05 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2008-02-25 18:09:51
Subject: Re: build environment: a different makefile
Previous:From: Gregory StarkDate: 2008-02-25 18:06:36
Subject: Re: Questions about indexes with text_pattern_ops

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group