Created attachment 389408 [details, diff] Patch against DateTime-TimeZone-1.600.0.ebuild All dev-perl/DateTime-TimeZone packages have bundled pre-compiled perl modules for each timezone. These modules generated by bundled tool "parse_olson". Latest in-portage dev-perl/DateTime-TimeZone-1.640.0 bundles modules generated from tzdata-2013h that is very outdated. I'm attached patch against DateTime-TimeZone-1.600.0.ebuild to recompile bundled modules against latest stable [in Gentoo] tzdata-2014i. Updated ebuild also available in vortex overlay: https://github.com/nE0sIghT/vortex-overlay/blob/master/dev-perl/DateTime-TimeZone/DateTime-TimeZone-1.600.0-r1.ebuild
It is ugly solution, to be honest. There is version 1.79 I belive this release contains a fix. I will add it soon.
(In reply to Mikle Kolyada from comment #1) > It is ugly solution, to be honest. There is version 1.79 I belive this > release contains a fix. I will add it soon. Version 1.79 contains time zone modules from tzdata-2014j: http://cpansearch.perl.org/src/DROLSKY/DateTime-TimeZone-1.79/lib/DateTime/TimeZone/Europe/Moscow.pm So no problems with just bumping version
I'd vote for re-generating the data during merge.
I feel changing the built data so that the installed version differs from upstream might result in support problems if people are working with upstream. ie: "I have blah blah problem with timezones, I'm using Foo::Bar 1.2" "Thats weird, that shouldn't be happening, that was fixed in 1.2" <much later> "Oh, turns out I'm regenerating the tzdata myself because gentoo think thats a good idea". => DateTime::TimeZone is more or less assuming certain things about what it ships with. However, if you wish to have a flag like USE="system-tzdata" that adds some kind of tzdata dep and regenerates it from that, I'm not opposed. It lets users keep the pieces. But having the ebuild itself define what upstream tzdata is used in the ebuild itself might be a bad idea for maintenance reasons. The worst that could happen is somebody might bump the ebuild version, but _not_ the tzdata version, which will in practice give users an ebuild *claiming* to have newer tzdata, but in fact, having the same tzdata.
lets wait a couple of days before fixed version goes stable
Arches, please test and mark stable: =dev-perl/DateTime-TimeZone-1.810.0 target KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Stable for HPPA.
Stable for all.
