Re: The State of the TimeZone in Debian

gregor herrmann wrote:
>Before I file ITP bugs and upload them, I'd like to have some review;

I'll look at them shortly.

>What I'm also missing is the big picture how those package relate to
>the good old DateTime::TimeZone with its tzfiles-converted-to-pm-files.
>It's supposed to use Time::OlsonTZ::Data at some point, right?

Right.  There's a rewrite of DateTime::TimeZone, sitting in my repo,
that does away with the pm-per-zone modules and uses Time::OlsonTZ::Data
instead.  We scheduled the official replacement of DateTime::TimeZone
for 2012-09-01, but I was out of action for a few months due to a bout
of depression, so I missed that.  I'm picking up the pieces now, and
we'll reschedule for some time in 2013.

Whereas the current DateTime::TimeZone is volatile, due to including all
the timezone data, the rewritten DateTime::TimeZone will not be volatile.
The volatility is being localised in Time::OlsonTZ::Data (and, for you,
the underlying tzdata package).

>Do we need something else? I think we can skip
>Time::OlsonTZ::Download, since we want to use our tzdata anyway,
>right? And I think App::olson is also not required.

T:OTZ:Download is a development tool.  The build process for T:OTZ:Data
uses it, even when working from local source, but your modified form
of T:OTZ:Data build could manage without it if you tweak the prebuild
script a bit.  There's no need for ordinary users to have T:OTZ:Download.

It would be nice to have App::olson packaged.  (Preferably as "olson"
rather than "libapp-olson-perl", because it's intended to be used as
a command-line program rather than as a Perl module.)  It is intended
for ordinary users.  But it's not necessary to package it at this stage:
none of the timezone infrastructure depends on it.  It is cleanly layered
on top of Time::OlsonTZ::Data.

-zefram