On Fri, 2007-11-09 at 09:25 -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera <alvherre@CommandPrompt.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
