Re: tzcode update - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: tzcode update
Date
Msg-id 47B2EC4E.9060206@enterprisedb.com
Whole thread Raw
In response to Re: tzcode update  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: tzcode update
List 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

pgsql-patches by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: tzcode update
Next
From: Tom Lane
Date:
Subject: Re: tzcode update