Re: New tzdata available

Hi,

ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz

Per announcement:

"...is now available; this reflects changes for Cuba and Syria
circulated earlier this week on the time zone mailing list.

There are no code changes, so there's no tzcode2007i; tzcood2007h
remains current."

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Devrim GÜNDÜZ napsal(a):
> Hi,
>
> ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz
>
> Per announcement:
>
> "...is now available; this reflects changes for Cuba and Syria
> circulated earlier this week on the time zone mailing list.
>
> There are no code changes, so there's no tzcode2007i; tzcood2007h
> remains current."

I think we need some different mechanism how to deliver timezone updated. Bump
version and rebuild everything when new timezone files are released is not good
idea, especially in case when most unix packagers use system timezone.

Zdenek

Zdenek Kotala wrote:
> Devrim GÜNDÜZ napsal(a):
>> Hi,
>> ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz
>> Per announcement:
>> "...is now available; this reflects changes for Cuba and Syria
>> circulated earlier this week on the time zone mailing list.
>> There are no code changes, so there's no tzcode2007i; tzcood2007h
>> remains current."
>
> I think we need some different mechanism how to deliver timezone updated.
> Bump version and rebuild everything when new timezone files are released is
> not good idea, especially in case when most unix packagers use system
> timezone.

Agreed.

Even when the system TZ is not used, we could deliver our "zic"
executable (pgzic?) and let the user drop the latest tzdata somewhere
and recompile it.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)

Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> Zdenek Kotala wrote:
>> I think we need some different mechanism how to deliver timezone updated.

> Even when the system TZ is not used, we could deliver our "zic"
> executable (pgzic?) and let the user drop the latest tzdata somewhere
> and recompile it.

Well, a person who builds from source has already got the zic program;
all we need do is document someplace (more visible than now) how to drop
the tzdata update into the source tree and reinstall the files.

For people using prebuilt packages, it's really the packager's problem.
I think most packagers are going to move to depending on a system
timezone DB if at all possible.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
>> Zdenek Kotala wrote:
>>> I think we need some different mechanism how to deliver timezone updated.
>
>> Even when the system TZ is not used, we could deliver our "zic"
>> executable (pgzic?) and let the user drop the latest tzdata somewhere
>> and recompile it.
>
> Well, a person who builds from source has already got the zic program;
> all we need do is document someplace (more visible than now) how to drop
> the tzdata update into the source tree and reinstall the files.
>
> For people using prebuilt packages, it's really the packager's problem.
> I think most packagers are going to move to depending on a system
> timezone DB if at all possible.

Still need a solution for those where it's not possible (hint: Windows).
Not saying it has to be what's there now, but there has to be something
workable.

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> For people using prebuilt packages, it's really the packager's problem.
>> I think most packagers are going to move to depending on a system
>> timezone DB if at all possible.

> Still need a solution for those where it's not possible (hint: Windows).
> Not saying it has to be what's there now, but there has to be something
> workable.

Are Windows users accustomed to having up-to-the-minute timezone
information? Maybe there's something I don't know about Microsoft's
update practices, but I would have thought that the expectations on that
platform would be pretty darn low.

regards, tom lane

Tom Lane wrote:
>
> Are Windows users accustomed to having up-to-the-minute timezone
> information? Maybe there's something I don't know about Microsoft's
> update practices, but I would have thought that the expectations on that
> platform would be pretty darn low.
>
>
>

No, they push updates fairly aggressively. Of course, that's when they
have fixes for the problems ... but I would normally expect them to be
well on top of timezone changes.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Are Windows users accustomed to having up-to-the-minute timezone
>> information? Maybe there's something I don't know about Microsoft's
>> update practices, but I would have thought that the expectations on that
>> platform would be pretty darn low.
>>
>>
>>
>
> No, they push updates fairly aggressively. Of course, that's when they
> have fixes for the problems ... but I would normally expect them to be
> well on top of timezone changes.

At least for "common places". They certainly pushed out TZ updates for
the US changes and the NZ changes recently through their Windows
Update/Automatic Updates/WSUS service.

//Magnus

On 11/8/07, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> Andrew Dunstan wrote:
> > Tom Lane wrote:

> >> Are Windows users accustomed to having up-to-the-minute timezone
> >> information? Maybe there's something I don't know about Microsoft's
> >> update practices, but I would have thought that the expectations on that
> >> platform would be pretty darn low.

> > No, they push updates fairly aggressively. Of course, that's when they
> > have fixes for the problems ... but I would normally expect them to be
> > well on top of timezone changes.

> At least for "common places". They certainly pushed out TZ updates for
> the US changes and the NZ changes recently through their Windows
> Update/Automatic Updates/WSUS service.

Unfortunately, until Vista there was no architecture in place to track
historical changes. On older versions, the latest zone calendar is
the one that's in effect for all dates (so current US rules apply to
last year's dates too, and we get inaccurate times for them). The OS
services aren't suitable as a replacement for tzdata.

I've been wondering lately why it isn't just stored in the database somewhere.

On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote:
> On 11/8/07, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> > Andrew Dunstan wrote:
> > > Tom Lane wrote:
>
> > >> Are Windows users accustomed to having up-to-the-minute timezone
> > >> information? Maybe there's something I don't know about Microsoft's
> > >> update practices, but I would have thought that the expectations on that
> > >> platform would be pretty darn low.
>
> > > No, they push updates fairly aggressively. Of course, that's when they
> > > have fixes for the problems ... but I would normally expect them to be
> > > well on top of timezone changes.
>
> > At least for "common places". They certainly pushed out TZ updates for
> > the US changes and the NZ changes recently through their Windows
> > Update/Automatic Updates/WSUS service.
>
> Unfortunately, until Vista there was no architecture in place to track
> historical changes. On older versions, the latest zone calendar is
> the one that's in effect for all dates (so current US rules apply to
> last year's dates too, and we get inaccurate times for them). The OS
> services aren't suitable as a replacement for tzdata.

That only goes to *what* they update ;-) And the Windows timezone handling
in general is very very limited, which is one of the reasons we went with
doing our own timezone library in the first place.

They still give you the latest updates quickly, which is what was Toms
question.

> I've been wondering lately why it isn't just stored in the database somewhere.

That's a different question. One reason is that we wanted files compatible
with the stuff that was included in the zic library. IIRC there was other
reasons as well, but I don't remember what they were :-)

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote:
>> I've been wondering lately why it isn't just stored in the database somewhere.

> That's a different question. One reason is that we wanted files compatible
> with the stuff that was included in the zic library.

I think the one lesson we have entirely absorbed is that we don't want
to be in-the-loop for timezone updates. I don't see how keeping the
info "inside" the DB would help that.

Plan B would be to take out contracts on all the banana-republic
politicians who think that changing DST laws with a month's notice
is a pleasant pastime. I fear we lack the resources for that,
unfortunately.

regards, tom lane

On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Thu, Nov 08, 2007 at 05:46:08PM -0800, Trevor Talbot wrote:
> >> I've been wondering lately why it isn't just stored in the database somewhere.
>
> > That's a different question. One reason is that we wanted files compatible
> > with the stuff that was included in the zic library.
>
> I think the one lesson we have entirely absorbed is that we don't want
> to be in-the-loop for timezone updates. I don't see how keeping the
> info "inside" the DB would help that.

Yeah.

> Plan B would be to take out contracts on all the banana-republic
> politicians who think that changing DST laws with a month's notice
> is a pleasant pastime. I fear we lack the resources for that,
> unfortunately.

You're referring to countries like the United States and New Zealand ;-)

On a more serious note, we *could* make a simple ZIP file available with
files to drop in the timezone directory for such urgent updates, since
the majority of users don't need them. But then still update to the
latest TZ data whenever we release, and possibly still do TZ-related
releases for cases when it's a large country (like the US...) that make
the change...

Seems reasonable?

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote:
>> Plan B would be to take out contracts on all the banana-republic
>> politicians who think that changing DST laws with a month's notice
>> is a pleasant pastime. I fear we lack the resources for that,
>> unfortunately.

> You're referring to countries like the United States and New Zealand ;-)

Be fair --- the USA did give us a couple years' notice. Though I'm
still prepared to vote against any congresscritter who stands up and
says that was a good idea. (I'm still driving a car whose GPS does not
know about the change, and if any political animal happens to be reading
this: it is not a good idea to tick off your constituents in the week
before November elections.)

> On a more serious note, we *could* make a simple ZIP file available with
> files to drop in the timezone directory for such urgent updates, since
> the majority of users don't need them.

Sure, it's doable if anyone cares that much. But I think we should
spend more energy on scheming how not to be involved.

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote:
>>> Plan B would be to take out contracts on all the banana-republic
>>> politicians who think that changing DST laws with a month's notice
>>> is a pleasant pastime. I fear we lack the resources for that,
>>> unfortunately.
>
>> You're referring to countries like the United States and New Zealand ;-)
>
> Be fair --- the USA did give us a couple years' notice.

Yes, original global change yes, but Indiana state changes was announced
two months ago ;-).

See
http://www.courierpress.com/news/2007/sep/20/some-counties-get-ok-move-back-eastern-time-zone/

Zdenek

On Fri, 2007-11-09 at 02:56 -0500, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Fri, 2007-11-09 at 02:26 -0500, Tom Lane wrote:
> >> Plan B would be to take out contracts on all the banana-republic
> >> politicians who think that changing DST laws with a month's notice
> >> is a pleasant pastime. I fear we lack the resources for that,
> >> unfortunately.
>
> > You're referring to countries like the United States and New Zealand ;-)
>
> Be fair --- the USA did give us a couple years' notice.

Not for the latest changes, IIRC.

> Though I'm
> still prepared to vote against any congresscritter who stands up and
> says that was a good idea. (I'm still driving a car whose GPS does not
> know about the change, and if any political animal happens to be reading
> this: it is not a good idea to tick off your constituents in the week
> before November elections.)

:-)

> > On a more serious note, we *could* make a simple ZIP file available with
> > files to drop in the timezone directory for such urgent updates, since
> > the majority of users don't need them.
>
> Sure, it's doable if anyone cares that much. But I think we should
> spend more energy on scheming how not to be involved.

Sure. But how can we do that for a platform that doesn't have compatible
zic files as part of the platform. I know Windows is such, I have no
idea if there are others, but that doesn't change the need to have a
solution for this case.

//Magnus

"Magnus Hagander" <magnus(at)hagander(dot)net> writes:

> On Fri, 2007-11-09 at 02:56 -0500, Tom Lane wrote:
>
>> Be fair --- the USA did give us a couple years' notice.
>
> Not for the latest changes, IIRC.

It didn't match my recollection either. But apparently Tom is almost right.
The Energy Policy Act of 2005 established the new rules. It was introduced
April 18th in the House and signed August 8th. The first effect it had was
April 1st 2007, just slightly less than 2 years after being introduced.

Of course any change to timezone rules has effects immediately for people
dealing with future dates so it isn't clear how to judge the amount of
warning.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

On Fri, 2007-11-09 at 10:04 +0000, Gregory Stark wrote:
> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>
> > On Fri, 2007-11-09 at 02:56 -0500, Tom Lane wrote:
> >
> >> Be fair --- the USA did give us a couple years' notice.
> >
> > Not for the latest changes, IIRC.
>
> It didn't match my recollection either. But apparently Tom is almost right.
> The Energy Policy Act of 2005 established the new rules. It was introduced
> April 18th in the House and signed August 8th. The first effect it had was
> April 1st 2007, just slightly less than 2 years after being introduced.
>
Those aren't the changes I'm talking about. Zdenek said it (I think it
was him), the Indiana changes are different.

But, that's irrelevant to this discussion, really. Politicians *will*
continue to do this :-)

//Magnus

Magnus Hagander wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> >> Zdenek Kotala wrote:
> >>> I think we need some different mechanism how to deliver timezone updated.
> >
> >> Even when the system TZ is not used, we could deliver our "zic"
> >> executable (pgzic?) and let the user drop the latest tzdata somewhere
> >> and recompile it.
> >
> > Well, a person who builds from source has already got the zic program;
> > all we need do is document someplace (more visible than now) how to drop
> > the tzdata update into the source tree and reinstall the files.
> >
> > For people using prebuilt packages, it's really the packager's problem.
> > I think most packagers are going to move to depending on a system
> > timezone DB if at all possible.
>
> Still need a solution for those where it's not possible (hint: Windows).
> Not saying it has to be what's there now, but there has to be something
> workable.

I think the first step is to install the zic binary along the rest of
the stuff, so that a user without the source tree can compile the tzdata
package. Unless the compiled representation is portable, which I kinda
doubt?

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"The only difference is that Saddam would kill you on private, where the
Americans will kill you in public" (Mohammad Saleh, 39, a building contractor)

On Fri, 2007-11-09 at 09:25 -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> > >> Zdenek Kotala wrote:
> > >>> I think we need some different mechanism how to deliver timezone updated.
> > >
> > >> Even when the system TZ is not used, we could deliver our "zic"
> > >> executable (pgzic?) and let the user drop the latest tzdata somewhere
> > >> and recompile it.
> > >
> > > Well, a person who builds from source has already got the zic program;
> > > all we need do is document someplace (more visible than now) how to drop
> > > the tzdata update into the source tree and reinstall the files.
> > >
> > > For people using prebuilt packages, it's really the packager's problem.
> > > I think most packagers are going to move to depending on a system
> > > timezone DB if at all possible.
> >
> > Still need a solution for those where it's not possible (hint: Windows).
> > Not saying it has to be what's there now, but there has to be something
> > workable.
>
> I think the first step is to install the zic binary along the rest of
> the stuff, so that a user without the source tree can compile the tzdata
> package. Unless the compiled representation is portable, which I kinda
> doubt?

At least they're not guaranteed to be. So yeah, we could ship the zic
binary and instructions on how to update the files, or we could ship the
files themselves.

A big question is, are any platforms *other* than Windows really doing
this? Or do all other platforms use the system TZ data? If it's just
Windows, then we're probably better off just shipping a ZIP file with
it, since that'll be the easiest for the user... And building just that
ZIP file should be a *lot* easier than building a full release package.

This all assumes that we'll still put the latest-available zic data in
before each of our releases - just that we don't release because of zic
data updates. I haven't heard any objections to that, so I'm assuming
that stays.

//Magnus

Alvaro Herrera wrote:

>
> I think the first step is to install the zic binary along the rest of
> the stuff, so that a user without the source tree can compile the tzdata
> package. Unless the compiled representation is portable, which I kinda
> doubt?

Maybe wild idea, what's about use buildfarm to upload database for
tested platform in defined place?

Zdenek

Magnus Hagander wrote:
> On Fri, 2007-11-09 at 09:25 -0300, Alvaro Herrera wrote:
>> Magnus Hagander wrote:
>>> Tom Lane wrote:
>>>> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
>>>>> Zdenek Kotala wrote:
>>>>>> I think we need some different mechanism how to deliver timezone updated.
>>>>> Even when the system TZ is not used, we could deliver our "zic"
>>>>> executable (pgzic?) and let the user drop the latest tzdata somewhere
>>>>> and recompile it.
>>>> Well, a person who builds from source has already got the zic program;
>>>> all we need do is document someplace (more visible than now) how to drop
>>>> the tzdata update into the source tree and reinstall the files.
>>>>
>>>> For people using prebuilt packages, it's really the packager's problem.
>>>> I think most packagers are going to move to depending on a system
>>>> timezone DB if at all possible.
>>> Still need a solution for those where it's not possible (hint: Windows).
>>> Not saying it has to be what's there now, but there has to be something
>>> workable.
>> I think the first step is to install the zic binary along the rest of
>> the stuff, so that a user without the source tree can compile the tzdata
>> package. Unless the compiled representation is portable, which I kinda
>> doubt?
>
> At least they're not guaranteed to be. So yeah, we could ship the zic
> binary and instructions on how to update the files, or we could ship the
> files themselves.
>
> A big question is, are any platforms *other* than Windows really doing
> this? Or do all other platforms use the system TZ data? If it's just
> Windows, then we're probably better off just shipping a ZIP file with
> it, since that'll be the easiest for the user... And building just that
> ZIP file should be a *lot* easier than building a full release package.

In 8.3 you have configure option, but for 8.0-8.2 branches you must make
some extra magic to integrate postgres with system timezone files. How
Tom mentioned for packager it is OK, but for users who want to compile
postgres 8.0-8.2 by them self is little bit complicated.

Another interesting questions are what postgres does when timezone files
are changed? Does it need SIGHUP to invoke rereading? What is impact on
current running transaction when tz file is changed?

Zdenek

On Fri, 2007-11-09 at 14:23 +0100, Zdenek Kotala wrote:
> Magnus Hagander wrote:
> > On Fri, 2007-11-09 at 09:25 -0300, Alvaro Herrera wrote:
> >> Magnus Hagander wrote:
> >>> Tom Lane wrote:
> >>>> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> >>>>> Zdenek Kotala wrote:
> >>>>>> I think we need some different mechanism how to deliver timezone updated.
> >>>>> Even when the system TZ is not used, we could deliver our "zic"
> >>>>> executable (pgzic?) and let the user drop the latest tzdata somewhere
> >>>>> and recompile it.
> >>>> Well, a person who builds from source has already got the zic program;
> >>>> all we need do is document someplace (more visible than now) how to drop
> >>>> the tzdata update into the source tree and reinstall the files.
> >>>>
> >>>> For people using prebuilt packages, it's really the packager's problem.
> >>>> I think most packagers are going to move to depending on a system
> >>>> timezone DB if at all possible.
> >>> Still need a solution for those where it's not possible (hint: Windows).
> >>> Not saying it has to be what's there now, but there has to be something
> >>> workable.
> >> I think the first step is to install the zic binary along the rest of
> >> the stuff, so that a user without the source tree can compile the tzdata
> >> package. Unless the compiled representation is portable, which I kinda
> >> doubt?
> >
> > At least they're not guaranteed to be. So yeah, we could ship the zic
> > binary and instructions on how to update the files, or we could ship the
> > files themselves.
> >
> > A big question is, are any platforms *other* than Windows really doing
> > this? Or do all other platforms use the system TZ data? If it's just
> > Windows, then we're probably better off just shipping a ZIP file with
> > it, since that'll be the easiest for the user... And building just that
> > ZIP file should be a *lot* easier than building a full release package.
>
> In 8.3 you have configure option, but for 8.0-8.2 branches you must make
> some extra magic to integrate postgres with system timezone files. How
> Tom mentioned for packager it is OK, but for users who want to compile
> postgres 8.0-8.2 by them self is little bit complicated.
>
> Another interesting questions are what postgres does when timezone files
> are changed? Does it need SIGHUP to invoke rereading? What is impact on
> current running transaction when tz file is changed?

That won't happen. The first time a timezone is loaded, it's cached. If
this happens in the postmaster, it'll be inherited by children. If it
happens in the backend, it'll still be used until that backend exits. So
there is no way for the TZ information to change on anything currently
running. But to make sure everything is updated, you need to restart the
whole cluster.

The one thing you have there is that if you have two related timezone
updates - you can theoretically notice one change and not the other,
since the replacement isn't atomic. But I really can't get excited about
that one.

//Magnus

Zdenek Kotala wrote:
> Alvaro Herrera wrote:
>
>>
>> I think the first step is to install the zic binary along the rest of
>> the stuff, so that a user without the source tree can compile the tzdata
>> package. Unless the compiled representation is portable, which I kinda
>> doubt?
>
> Maybe wild idea, what's about use buildfarm to upload database for
> tested platform in defined place?
>
>
>

No, that's really not what the buildfarm server is for. We have plenty
of places where we can and do put prebuilt binary packages. We have a
whole distributed download farm, in fact.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Zdenek Kotala wrote:
>> Alvaro Herrera wrote:
>>
>>>
>>> I think the first step is to install the zic binary along the rest of
>>> the stuff, so that a user without the source tree can compile the tzdata
>>> package. Unless the compiled representation is portable, which I kinda
>>> doubt?
>>
>> Maybe wild idea, what's about use buildfarm to upload database for
>> tested platform in defined place?
>>
>>
>>
>
> No, that's really not what the buildfarm server is for. We have plenty
> of places where we can and do put prebuilt binary packages. We have a
> whole distributed download farm, in fact.

I meant to use build farm member for uploading their generated timezone
files together with test result and put them somewhere on
ftp.postgresql.org. This feature should be disabled by default. However
it invoke a lot of questions how to do it secure... Maybe it is really
too wild...

Zdenek

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Another interesting questions are what postgres does when timezone files
> are changed? Does it need SIGHUP to invoke rereading? What is impact on
> current running transaction when tz file is changed?

This falls into the category of "get a life". There is no program in
the world that automatically reacts to timezone data updates. The
normal expectation is that you reboot, because such always-on daemons as
"cron" will already have read the timezone file into memory. The libc
API doesn't even provide a way that one could tell libc to re-read after
SIGHUP, say.

regards, tom lane

Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> I think the first step is to install the zic binary along the rest of
> the stuff, so that a user without the source tree can compile the tzdata
> package. Unless the compiled representation is portable, which I kinda
> doubt?

Actually, it is. In fact, it's so portable that their recent extension
to 64-bits (for Y2038) is fully upward compatible with existing programs.

So one solution is to just provide a zipfile of the updated timezone
file tree and tell people to drop it into their installations.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
>> I think the first step is to install the zic binary along the rest of
>> the stuff, so that a user without the source tree can compile the tzdata
>> package. Unless the compiled representation is portable, which I kinda
>> doubt?
>
> Actually, it is. In fact, it's so portable that their recent extension
> to 64-bits (for Y2038) is fully upward compatible with existing programs.
>
> So one solution is to just provide a zipfile of the updated timezone
> file tree and tell people to drop it into their installations.

+1 it seems a best solution for me.

Zdenek

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> > I think the first step is to install the zic binary along the rest of
> > the stuff, so that a user without the source tree can compile the tzdata
> > package. Unless the compiled representation is portable, which I kinda
> > doubt?
>
> Actually, it is. In fact, it's so portable that their recent extension
> to 64-bits (for Y2038) is fully upward compatible with existing programs.
>
> So one solution is to just provide a zipfile of the updated timezone
> file tree and tell people to drop it into their installations.

That's the most convenient, I agree.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
Hi! I'm a .signature virus!
cp me into your .signature file to help me spread!