zic data updates
Current beta seems to have the 2006k version of the zic database. The current
zic database is version 2006n however. Since this update does not include
source code but just data files I would vote to do the update in beta, what
do others think?
One prominent update concerns Brazil which changes to summer time one week
later this year (next weekend actually).
Joachim
"Joachim Wieland" <joe@mcknight.de> writes:
Current beta seems to have the 2006k version of the zic database. The current
zic database is version 2006n however. Since this update does not include
source code but just data files I would vote to do the update in beta, what
do others think?
Sigh, I just updated that six weeks ago ...
regards, tom lane
Tom Lane wrote:
"Joachim Wieland" <joe@mcknight.de> writes:
Current beta seems to have the 2006k version of the zic database. The current
zic database is version 2006n however. Since this update does not include
source code but just data files I would vote to do the update in beta, what
do others think?Sigh, I just updated that six weeks ago ...
Tom has done the zic updates to 2006n.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Tom has done the zic updates to 2006n.
What about update it to 2006o? It's from 11/06/2006 [1]ftp://elsie.nci.nih.gov/pub/.
[1]: ftp://elsie.nci.nih.gov/pub/
--
Euler Taveira de Oliveira
http://www.timbira.com/
Euler Taveira de Oliveira <euler@timbira.com> writes:
Bruce Momjian wrote:
Tom has done the zic updates to 2006n.
What about update it to 2006o? It's from 11/06/2006 [1].
[ shrug... ] And by the time we release 8.2, it'll no doubt have
changed twice more. Folks who live in countries where DST rules change
with no notice will probably have to get used to downloading and
installing zic updates for themselves, because there's no chance that
our releases will be perfectly up to date.
For the Red Hat RPMs, I've been considering modifying the installed
file tree to link to /usr/share/zoneinfo so that Postgres would track
routine updates to the tzdata package automatically. This relies on
knowing that the system uses the same zic database format we do, and
where it keeps it, so I fear it's not a very portable answer :-(.
But there are definitely downsides as well as upsides to maintaining
our own timezone support.
regards, tom lane
Tom Lane wrote:
[ shrug... ] And by the time we release 8.2, it'll no doubt have
changed twice more. Folks who live in countries where DST rules change
with no notice will probably have to get used to downloading and
installing zic updates for themselves, because there's no chance that
our releases will be perfectly up to date.
Maybe we need to point out somewhere in the docs how to update our zic
database. Upgrade to a newer postgresql version is not the "right"
answer though. Maybe a small note in Chapter 14 or 22?
For the Red Hat RPMs, I've been considering modifying the installed
file tree to link to /usr/share/zoneinfo so that Postgres would track
routine updates to the tzdata package automatically. This relies on
knowing that the system uses the same zic database format we do, and
where it keeps it, so I fear it's not a very portable answer :-(.
No, it's not. Separated projects have different directions sometimes so
it's not worth the risk.
--
Euler Taveira de Oliveira
http://www.timbira.com/