Thread: TODO item: update source/timezone for 64-bit tz files
Back when we converted src/timezone to use int64 for pg_time_t, we
wondered what to do about extending the compiled timezone data file
format for int64, so that it would work for years beyound 2038. We
shelved the problem waiting to see what the upstream zic folks would do.
Well, it looks like they've done something about it. So I think we
ought to plan on updating our code to match theirs, so that we fix the
y2038 problem while keeping it possible to use a standard zic-database
installation with Postgres. This is not urgent (I surely see no need
to hold up 8.2 to fix it), but it ought to go on the TODO list.
regards, tom lane
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --------------------------------------------------------------------------- Tom Lane wrote: > Back when we converted src/timezone to use int64 for pg_time_t, we > wondered what to do about extending the compiled timezone data file > format for int64, so that it would work for years beyound 2038. We > shelved the problem waiting to see what the upstream zic folks would do. > Well, it looks like they've done something about it. So I think we > ought to plan on updating our code to match theirs, so that we fix the > y2038 problem while keeping it possible to use a standard zic-database > installation with Postgres. This is not urgent (I surely see no need > to hold up 8.2 to fix it), but it ought to go on the TODO list. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sep 17, 2006, at 2:34 , Tom Lane wrote: > Back when we converted src/timezone to use int64 for pg_time_t, we > wondered what to do about extending the compiled timezone data file > format for int64, so that it would work for years beyound 2038. We > shelved the problem waiting to see what the upstream zic folks > would do. > Well, it looks like they've done something about it. So I think we > ought to plan on updating our code to match theirs, so that we fix the > y2038 problem while keeping it possible to use a standard zic-database > installation with Postgres. This is not urgent (I surely see no need > to hold up 8.2 to fix it), but it ought to go on the TODO list. > > regards, tom lane Did this get fixed? I don't see it in the release notes for 8.2 or on the current TODO. Michael Glaesemann grzm seespotcode net
Michael Glaesemann <grzm@seespotcode.net> writes:
> Did this get fixed? I don't see it in the release notes for 8.2 or on
> the current TODO.
No, nothing's been done. It's going to be a minor PITA, likely, since
our sources have diverged from upstream --- someone will have to go
through the upstream changes by hand and apply them :-( Any volunteers?
regards, tom lane
On Jan 11, 2007, at 12:51 , Tom Lane wrote: > Michael Glaesemann <grzm@seespotcode.net> writes: >> Did this get fixed? I don't see it in the release notes for 8.2 or on >> the current TODO. > > No, nothing's been done. It's going to be a minor PITA, likely, since > our sources have diverged from upstream --- someone will have to go > through the upstream changes by hand and apply them :-( Any > volunteers? I just want to make sure it gets on the TODO if it hasn't been done. Thanks for confirming. Bruce, could this get added? Michael Glaesemann grzm seespotcode net
Michael Glaesemann wrote:
>
> On Jan 11, 2007, at 12:51 , Tom Lane wrote:
>
> > Michael Glaesemann <grzm@seespotcode.net> writes:
> >> Did this get fixed? I don't see it in the release notes for 8.2 or on
> >> the current TODO.
> >
> > No, nothing's been done. It's going to be a minor PITA, likely, since
> > our sources have diverged from upstream --- someone will have to go
> > through the upstream changes by hand and apply them :-( Any
> > volunteers?
>
> I just want to make sure it gets on the TODO if it hasn't been done.
> Thanks for confirming. Bruce, could this get added?
Thanks. I was not aware of this item. Added:
o Extend timezone code to allow 64-bit values so we can represent years beyond 2038
http://archives.postgresql.org/pgsql-hackers/2006-09/msg01363.php
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Added to TODO: * Update our code to handle 64-bit timezone files to match the zic source code, which now uses them --------------------------------------------------------------------------- Tom Lane wrote: > Back when we converted src/timezone to use int64 for pg_time_t, we > wondered what to do about extending the compiled timezone data file > format for int64, so that it would work for years beyound 2038. We > shelved the problem waiting to see what the upstream zic folks would do. > Well, it looks like they've done something about it. So I think we > ought to plan on updating our code to match theirs, so that we fix the > y2038 problem while keeping it possible to use a standard zic-database > installation with Postgres. This is not urgent (I surely see no need > to hold up 8.2 to fix it), but it ought to go on the TODO list. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +