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
