Re: [PATCHES] tzcode update
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Mon, Feb 18, 2008 at 04:32:58PM +0100, Bjorn Munch wrote: Ouch! This fails on our Solaris builds, because we build with the Solaris timezone files. And these apparently don't work beyond 2038 and don't know that Finland plans to have DST also in the summer of 2050... I haven't studied this in depth but I'm afraid the answer is fix your own timezone files? Or use the ones shipping with pg ;-) Yeah. I included the far-future cases in the committed patch specifically to make it obvious if you were using tz files that lacked post-2038 support. Agreed, we want to give people a notice. What we could do is to add comments to the expected output file, that would show up in regression.diffs, that explain what the failure means. I can't imagine that fixing this isn't pretty darn high on the Solaris to-do list, anyway. Yep, and PostgreSQL 8.4 won't be released for quite some time. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] tzcode update
On Mon, Feb 18, 2008 at 04:32:58PM +0100, Bjorn Munch wrote: On 13/02 10.51, Heikki Linnakangas wrote: Heikki Linnakangas wrote: I'll add some tests to cover timestamps 2038. Attached is a new patch, with a couple of new regression tests. No other changes. Ouch! This fails on our Solaris builds, because we build with the Solaris timezone files. And these apparently don't work beyond 2038 and don't know that Finland plans to have DST also in the summer of 2050... I haven't studied this in depth but I'm afraid the answer is fix your own timezone files? Or use the ones shipping with pg ;-) This sounds exactly like the problem scenario brought forward when the patch to use OS timezonedata was added. But I'd assume there are plans for Solaris to include this data as well in the future, no? You'll have to eventually //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] tzcode update
On 13/02 10.51, Heikki Linnakangas wrote: Heikki Linnakangas wrote: I'll add some tests to cover timestamps 2038. Attached is a new patch, with a couple of new regression tests. No other changes. Ouch! This fails on our Solaris builds, because we build with the Solaris timezone files. And these apparently don't work beyond 2038 and don't know that Finland plans to have DST also in the summer of 2050... I haven't studied this in depth but I'm afraid the answer is fix your own timezone files? -- Bjorn Munch Database Technology Group, Sun Microsystems Trondheim, Norway ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] tzcode update
Magnus Hagander [EMAIL PROTECTED] writes: On Mon, Feb 18, 2008 at 04:32:58PM +0100, Bjorn Munch wrote: Ouch! This fails on our Solaris builds, because we build with the Solaris timezone files. And these apparently don't work beyond 2038 and don't know that Finland plans to have DST also in the summer of 2050... I haven't studied this in depth but I'm afraid the answer is fix your own timezone files? Or use the ones shipping with pg ;-) Yeah. I included the far-future cases in the committed patch specifically to make it obvious if you were using tz files that lacked post-2038 support. I can't imagine that fixing this isn't pretty darn high on the Solaris to-do list, anyway. Financial apps doing, say, 30-year mortgage projections are broken *today* on platforms without post-Y2038 calendar support. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] tzcode update
On 18/02 14.22, Tom Lane wrote: I can't imagine that fixing this isn't pretty darn high on the Solaris to-do list, anyway. Financial apps doing, say, 30-year mortgage projections are broken *today* on platforms without post-Y2038 calendar support. Well, it IS mentioned in the BUGS section of at least one man page (localtime), so it's clearly a known problem. I don't know about 30-year mortgage, I don't think such financial apps care whether the day 30 days into the future has DST or not. :-) And apart from that, the date was correct. - Bjorn Munch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] tzcode update
Heikki Linnakangas [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: I'll add some tests to cover timestamps 2038. Attached is a new patch, with a couple of new regression tests. No other changes. Applied with minor revisions --- I found a couple of portability problems while testing here. int64_fast_t is already defined in some system headers and causes a conflict, so I just made it be int64 instead. Also there were undefined references to INT32_MIN and INT32_MAX, which could possibly have been fixed with more #include's, but I thought replacing them with a cast-based overflow check was at least as good. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] tzcode update
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Looking closer, I don't understand how that change was supposed to do
anything.
The point of that patch is to avoid an off-by-one result for years BC.
The direction of rounding in integer division with a negative numerator
is undefined in C (or at least used to be --- did C99 tighten this up?).
Oh, I see. In that case we're good. The corresponding new code in tzcode
actually looks like this:
! static int
! leaps_thru_end_of(const int y)
! {
! return (y = 0) ? (y / 4 - y / 100 + y / 400) :
! -(leaps_thru_end_of(-(y + 1)) + 1);
! }
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] tzcode update
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] tzcode update
Heikki Linnakangas [EMAIL PROTECTED] writes: Looking closer, I don't understand how that change was supposed to do anything. The point of that patch is to avoid an off-by-one result for years BC. The direction of rounding in integer division with a negative numerator is undefined in C (or at least used to be --- did C99 tighten this up?). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] tzcode update
Heikki Linnakangas [EMAIL PROTECTED] writes: I was not able to find anything like release notes that would list the differences between tzcode2003e, which I believe is the version that we included back then, and the latest version tzcode2007k. So I just took a diff between those, and deduced from there what has changed. Oh good, this has been on my to-do list for awhile ... but I'm happy to let you do it ;-) I don't really know how to test this. It passes the regression tests, after the fixes to pg_dst_next_boundary, but I was expecting there to be some failures now that we support timezones for timestamps outside the 32-bit time_t range. Apparently our tests don't cover that? Unless the 64-bit extension changed the semantics a lot more than I think, any given compiled tzdata file covers only a finite range of years. The extension makes it *possible* for the data to extend outside the time_t range, but you won't actually see a difference in behavior unless (a) you do extend the range (what's zic's default now?) and (b) you test a date falling within the extended range. So I'm not too surprised that there are no cases in the regression tests that notice. We should probably add some reaching out to 2100 or so. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
