Re: tzcode update
От | Heikki Linnakangas |
---|---|
Тема | Re: tzcode update |
Дата | |
Msg-id | 47B2EC4E.9060206@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: tzcode update ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: tzcode update
|
Список | 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 по дате отправления: