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

Re: interval madness ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Hans-Juergen Schoenig" <postgres(at)cybertec(dot)at>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: interval madness ...
Date: 2008-06-28 15:18:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Hans-Juergen Schoenig" <postgres(at)cybertec(dot)at> writes:
>> why do i get a different timezone just because of adding one more  century?
>> i cannot see an obvious reason.

> This thread may be enlightening:


> I can't find the message for the later commits but they weren't
> backpatched to 8.3 so unless you're using HEAD you won't get properly
> working timezones for post-2038

Yeah, that patch did get in earlier this year:

2008-02-16 16:16  tgl

	* src/: test/regress/expected/timestamptz.out,
	test/regress/sql/timestamptz.sql, timezone/README,
	timezone/ialloc.c, timezone/localtime.c, timezone/pgtz.c,
	timezone/pgtz.h, timezone/private.h, timezone/scheck.c,
	timezone/strftime.c, timezone/tzfile.h, timezone/zic.c: Update
	timezone code to track the upstream changes since 2003.  In
	particular this adds support for 64-bit tzdata files, which is
	needed to support DST calculations beyond 2038.  Add a regression
	test case to give some minimal confidence that that really works.
	Heikki Linnakangas

I believe the behavior now is that the code will assume the last known
DST rule for a zone applies indefinitely far into the future.  But in
8.3 and before all times past 2038 are taken as local standard time.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Reini UrbanDate: 2008-06-28 17:20:58
Subject: Re: stat() vs cygwin
Previous:From: Alvaro HerreraDate: 2008-06-28 14:48:04
Subject: Re: stat() vs cygwin

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