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

Re: tzcode update

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: tzcode update
Date: 2008-02-13 13:10:38
Message-ID: 47B2EC4E.9060206@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
I just noticed that I had accidentally reverted this change in the patch:

> 	/*
> 	 * Note: the point of adding 4800 is to ensure we make the same
> 	 * assumptions as Postgres' Julian-date routines about the placement of
> 	 * leap years in centuries BC, at least back to 4713BC which is as far as
> 	 * we'll go. This is effectively extending Gregorian timekeeping into
> 	 * pre-Gregorian centuries, which is a tad bogus but it conforms to the
> 	 * SQL spec...
> 	 */
> #define LEAPS_THRU_END_OF(y)	(((y) + 4800) / 4 - ((y) + 4800) / 100 + ((y) + 4800) / 400)

vs original in tzcode2003e:

> #define LEAPS_THRU_END_OF(y)    ((y) / 4 - (y) / 100 + (y) / 400)

Looking closer, I don't understand how that change was supposed to do 
anything. If I'm doing my math right, our +4800 version of the code can 
be written as: "y/4 - y/100 - y/400 + 1164". The only place this macro 
is used is this:

> 		days -= ((int64) (newy - y)) * DAYSPERNYEAR +
> 			LEAPS_THRU_END_OF(newy - 1) -
> 			LEAPS_THRU_END_OF(y - 1);

AFAICS, the constant " + 1164" is always cancelled out, making the 
exercise of adding 4800 a waste of time.

Am I missing something?

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2008-02-13 15:01:10
Subject: Re: tzcode update
Previous:From: Heikki LinnakangasDate: 2008-02-13 10:51:07
Subject: Re: tzcode update

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