FAQ
Another new version of my DT:TZ rewrite. CPAN-style tarball at

http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.902.tar.gz

Public git repo at

git://lake.fysh.org/zefram/DateTime-TimeZone.git

The zic issues affecting a couple of zones have now been resolved.
My zic patches were accepted upstream, and there's also a new version
of the tzfile format which tackles tricky rules a different way.
DT:TZ:Tzfile now handles the new tzfiles.

Time::OlsonTZ::Data now has the hooks that the Debian folks want in
order to roll their own version as part of their tzdata package.

I think we're now (at last) on the point of being able to replace DT:TZ
on CPAN.

-zefram

Search Discussions

  • Dave Rolsky at Sep 23, 2013 at 3:47 am

    On Sat, 21 Sep 2013, Zefram wrote:

    Another new version of my DT:TZ rewrite. CPAN-style tarball at

    http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.902.tar.gz

    Public git repo at

    git://lake.fysh.org/zefram/DateTime-TimeZone.git

    The zic issues affecting a couple of zones have now been resolved.
    My zic patches were accepted upstream, and there's also a new version
    of the tzfile format which tackles tricky rules a different way.
    DT:TZ:Tzfile now handles the new tzfiles.

    Time::OlsonTZ::Data now has the hooks that the Debian folks want in
    order to roll their own version as part of their tzdata package.

    I think we're now (at last) on the point of being able to replace DT:TZ
    on CPAN.
    So I tried installing the above tarball and it breaks a DateTime test
    - t/34set-tz.t

    It's just an error message change but it's an error message that other
    people might be looking for in their code too, since it's the kind of
    thing you might have to code around. I think it'd be good to keep this
    backwards compatible.

    The message is from an attempt to set a DateTime to an invalid time.
    Currently it's something like "Invalid local time for date in time zone
    ..."

    The new one is "local time 2013-03-10T02:04:00 does not exist in the
    America/Los_Angeles timezone due to offset change"

    Arguable the new message is better, but I don't think this is so important
    that it's worth break back compat for.


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Zefram at Sep 23, 2013 at 9:09 am

    Dave Rolsky wrote:
    So I tried installing the above tarball and it breaks a DateTime test
    - t/34set-tz.t
    Bah. We had a test break of exactly that nature back at DateTime 0.72,
    in t/36invalid-local.t, based on the same change of error message.
    The resolution was to change the test in DT 0.73 to accept both forms of
    the error message. I think we should change t/34set-tz.t in the same way.
    I think it'd be good to
    keep this backwards compatible.
    Error messages get improved and sensitive tests get broken. It's part of
    the normal traffic of CPAN. (I'm smoking a few percent of CPAN at work,
    and distropreffing to keep it all working, so I get to see quite a bit
    of this sort of thing.) It's not to be done frivolously, but nor should
    over-sensitive tests hold back genuine improvements in error handling.

    DateTime failing its tests is a blocker for DT:TZ 2. I think it's the
    only blocker atm.

    -zefram

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedSep 21, '13 at 1:08p
activeSep 23, '13 at 9:09a
posts3
users2
websitemetacpan.org...

2 users in discussion

Zefram: 2 posts Dave Rolsky: 1 post

People

Translate

site design / logo © 2019 Grokbase