FAQ
Hi guys,

I had a bit of trouble using timezones defined in the Olson etcetera
data file. I've had a stab at it and hopefully someone can do something
with my pull request:

   https://github.com/autarch/DateTime-TimeZone/pull/1

The diff can be seen here:

   https://github.com/alfie/DateTime-TimeZone/compare/autarch:master...master

Thanks,
Alfie

--
   Alfie John
   alfiej@fastmail.fm

Search Discussions

  • Zefram at Dec 3, 2013 at 12:13 pm

    Alfie John wrote:
    I had a bit of trouble using timezones defined in the Olson etcetera
    data file.
    DT:TZ intentionally doesn't support them. It's not aiming to provide
    precisely the semantics of the Olson database, and you'll see they're
    not listed in DT:TZ:Catalog. If you want to resolve zone names
    exactly as in the Olson database, use DateTime::TimeZone::Olson (a
    separate distribution). If you want timezones of fixed offset, prefer
    DateTime::TimeZone::OffsetOnly over the Olson Etc/ names.

    -zefram
  • Alfie John at Dec 3, 2013 at 11:43 pm

    On Tue, Dec 3, 2013, at 11:13 PM, Zefram wrote:
    Alfie John wrote:
    I had a bit of trouble using timezones defined in the Olson etcetera
    data file.
    DT:TZ intentionally doesn't support them.
    The --old option to parse_olson shows that is some support for them, it
    just doesn't do them correctly.
    It's not aiming to provide
    precisely the semantics of the Olson database, and you'll see they're
    not listed in DT:TZ:Catalog.
    Sorry, I've misunderstood the module then. I saw references to the Olson
    database in DT::TZ's documentation, I was under the assumption that it
    provided Olson timezones. If it doesn't aim to have mappings to all of
    the Olson entries is there a reason not to provide mappings with my
    patches? AFAICS it's only etcetera with valid zone data that is missing.
    If you want to resolve zone names
    exactly as in the Olson database, use DateTime::TimeZone::Olson (a
    separate distribution). If you want timezones of fixed offset, prefer
    DateTime::TimeZone::OffsetOnly over the Olson Etc/ names.
    I unfortunately need exact mappings, so OffsetOnly isn't an option. I've
    looked at DateTime::TimeZone::Olson, and it does what I want, but it
    looks like there's a bug (POSIX sign flipping which I've fixed in my
    patch to DateTime::TimeZone):

       #!/usr/bin/perl

       use strict;
       use warnings;

       use DateTime::Format::ISO8601;
       use DateTime::TimeZone::Olson qw(olson_tz);

       my $dt
         = DateTime::Format::ISO8601
         ->parse_datetime('2013-12-03T23:39:11')
         ->set_time_zone('UTC');

       print "$dt\n";

       $dt->set_time_zone(olson_tz("Etc/GMT+10"));
       print $dt,"\n";

    Expected output:

       2013-12-03T23:39:11
       2013-12-04T10:39:11

    Actual output:

       2013-12-03T23:39:11
       2013-12-03T13:39:11

    Alfie

    --
       Alfie John
       alfiej@fastmail.fm
  • Zefram at Dec 4, 2013 at 12:09 pm

    Alfie John wrote:
    If it doesn't aim to have mappings to all of
    the Olson entries is there a reason not to provide mappings with my
    patches?
    Dave Rolsky can answer better about the design intent. But there's
    a practical issue with changing right now: we're in the process of
    transitioning to a reimplementation of DT:TZ. Current state is that the
    new DT:TZ is ready, but DateTime has reacquired an over-sensitive test
    (of a type we fixed one instance of some time ago) that looks at timezone
    error messages and fails against the new DT:TZ.

    The new DT:TZ is based on DT:TZ:Olson, and it passes things not explicitly
    overridden through to DT:TZ:Olson. I believe this means it will accept
    Etc/GMT+10 and the like, with the Olson meaning. This difference
    isn't actually listed in the upgrading notes, which seems an oversight.
    (The upgrading notes do mention the Factory zone.)
    I unfortunately need exact mappings,
    So you also won't like DT:TZ's other deviations from Olson. DT:TZ uses
    Olson data to provide some of its zones, but its objective is broader and
    more nebulous than just providing access to the Olson data. DT:TZ:Olson,
    on the other hand, has the sole intention of providing access to the
    Olson database.
    looks like there's a bug (POSIX sign flipping which I've fixed in my
    patch to DateTime::TimeZone):
    I believe you're mistaken about the bug. (It seems to be a firm rule
    that everyone working with timezones gets the sign wrong occasionally.)
    Looking at your test case:
    print "$dt\n";
    $dt->set_time_zone(olson_tz("Etc/GMT+10"));
    print $dt,"\n";
    You've started with a DateTime in UT, and asked for it to be reexpressed
    in the Etc/GMT+10 zone, which (due to the strange sign convention) is a
    fixed ten hours *behind* UT. So I would expect the second time emitted
    to be ten hours earlier than the first one, as seen in your
    Actual output:

    2013-12-03T23:39:11
    2013-12-03T13:39:11
    You can also see this behaviour with date(1), on a platform where libc
    uses the Olson mechanism:

    $ TZ=UTC date -d '2013-12-03T23:39:11Z' +%FT%T%:z
    2013-12-03T23:39:11+00:00
    $ TZ=Etc/GMT+10 date -d '2013-12-03T23:39:11Z' +%FT%T%:z
    2013-12-03T13:39:11-10:00

    Also compare with a geographical zone that is ten hours behind UT:

    $ TZ=Pacific/Honolulu date -d '2013-12-03T23:39:11Z' +%FT%T%:z
    2013-12-03T13:39:11-10:00
    $ perl -MDateTime::Format::ISO8601 -MDateTime::TimeZone::Olson=olson_tz -lwe '$dt = DateTime::Format::ISO8601->parse_datetime("2013-12-03T23:39:11")->set_time_zone("UTC"); print $dt; $dt->set_time_zone(olson_tz("Pacific/Honolulu")); print $dt;'
    2013-12-03T23:39:11
    2013-12-03T13:39:11

    Internally, DT:TZ:Olson uses the tzfiles generated by Olson zic, and
    makes no attempt to interpret the zone names specially. So it would be
    essentially impossible for it to have a bug specific to the Etc/ zones.

    FWIW, the sign flipping in the Etc/ zone names is the product of a
    misunderstanding. The `POSIX' sign flip applies to SystemV-style zone
    specifiers, which are standardised in POSIX. (See DT:TZ:SystemV for
    Perl implementation.) In that system, for example, "XYZ+10" means the
    timezone is a constant ten hours behind UT, and refers to this time by
    the initialism "XYZ". So you could sensibly describe it (outside the
    POSIX context) as "XYZ = GMT-10". A timezone name "GMT+10" is *not*
    using the SystemV format: it's referring to a zone that's offset from
    GMT, not something that uses the initialism "GMT". So flipping the sign
    there doesn't make sense.

    The history of this is partly tied up with the switch to hierarchical zone
    names, because "Etc/GMT+10" doesn't clash with SystemV format, but the
    old "GMT+10" (which Olson used to have) did clash. Oslon used to have
    "GMT+10" meaning ten hours *ahead* of UT, the sensible sign convention,
    but the opposite of the offset you'd get from the SystemV specification
    with which it clashed. This could be sensibly resolved either by
    flipping the signs to match SystemV or by making the names non-clashing.
    The Olson folks did both, leading to a ridiculous arrangement.

    -zefram
  • Alfie John at Dec 4, 2013 at 10:33 pm

    On Wed, Dec 4, 2013, at 11:08 PM, Zefram wrote:
    Alfie John wrote:
    If it doesn't aim to have mappings to all of
    the Olson entries is there a reason not to provide mappings with my
    patches?
    Dave Rolsky can answer better about the design intent. But there's
    a practical issue with changing right now: we're in the process of
    transitioning to a reimplementation of DT:TZ. Current state is that the
    new DT:TZ is ready, but DateTime has reacquired an over-sensitive test
    (of a type we fixed one instance of some time ago) that looks at timezone
    error messages and fails against the new DT:TZ.
    No problem. I'll switch to DT::TZ::Olson for now until the new DT::TZ is
    out. Thanks for the heads up.
    looks like there's a bug (POSIX sign flipping which I've fixed in my
    patch to DateTime::TimeZone):
    I believe you're mistaken about the bug. (It seems to be a firm rule
    that everyone working with timezones gets the sign wrong occasionally.)
    Looking at your test case:
    print "$dt\n";
    $dt->set_time_zone(olson_tz("Etc/GMT+10"));
    print $dt,"\n";
    You've started with a DateTime in UT, and asked for it to be reexpressed
    in the Etc/GMT+10 zone, which (due to the strange sign convention) is a
    fixed ten hours *behind* UT. So I would expect the second time emitted
    to be ten hours earlier than the first one, as seen in your
    Actual output:

    2013-12-03T23:39:11
    2013-12-03T13:39:11
    Are you able to help fill the gaps in my understanding. This just
    confused me a bit...

    The current UTC is:

       $ perl -we 'use DateTime; print DateTime->now(),"\n"'
       2013-12-04T22:01:08

    I'm in Melbourne (Australia), which is 11 hour ahead of UTC (i.e.
    UTC+11):

       $ perl -we 'use DateTime; use DateTime::TimeZone::Olson qw{olson_tz};
       print DateTime->now(time_zone =>
       olson_tz("Australia/Melbourne")),"\n"'
       2013-12-05T09:01:08

    But here is what I get for Etc/GMT+11:

       $ perl -we 'use DateTime; use DateTime::TimeZone::Olson qw{olson_tz};
       print DateTime->now(time_zone => olson_tz("Etc/GMT+11")),"\n"'
       2013-12-04T11:01:08

    And again for Etc/GMT-11:

       $ perl -we 'use DateTime; use DateTime::TimeZone::Olson qw{olson_tz};
       print DateTime->now(time_zone => olson_tz("Etc/GMT-11")),"\n"'
       2013-12-05T09:01:08

    I guess it's a tautology seeing as that's what's defined in the etcetera
    file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?

    Alfie

    --
       Alfie John
       alfiej@fastmail.fm
  • Zefram at Dec 4, 2013 at 10:41 pm

    Alfie John wrote:
    I guess it's a tautology seeing as that's what's defined in the etcetera
    file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?
    Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see
    this by looking in the Olson etcetera file:

    # Zone NAME GMTOFF RULES FORMAT [UNTIL]
    Zone Etc/GMT-11 11 - GMT-11
    Zone Etc/GMT+11 -11 - GMT+11

    Such zic input, specifically the GMTOFF column, uses the usual sign
    convention; you can see here that the zone names use the opposite
    convention.

    -zefram
  • Alfie John at Dec 4, 2013 at 10:44 pm

    On Thu, Dec 5, 2013, at 09:40 AM, Zefram wrote:
    Alfie John wrote:
    I guess it's a tautology seeing as that's what's defined in the etcetera
    file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?
    Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see
    this by looking in the Olson etcetera file:

    # Zone NAME GMTOFF RULES FORMAT [UNTIL]
    Zone Etc/GMT-11 11 - GMT-11
    Zone Etc/GMT+11 -11 - GMT+11

    Such zic input, specifically the GMTOFF column, uses the usual sign
    convention; you can see here that the zone names use the opposite
    convention.
    Cool, thanks for the clarification.

    I'd hate to think of how much software out there assumes the same as I
    did.

    Alfie

    --
       Alfie John
       alfiej@fastmail.fm
  • Dave Rolsky at Dec 4, 2013 at 11:53 pm

    On Thu, 5 Dec 2013, Alfie John wrote:
    On Thu, Dec 5, 2013, at 09:40 AM, Zefram wrote:
    Alfie John wrote:
    I guess it's a tautology seeing as that's what's defined in the etcetera
    file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?
    Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see
    this by looking in the Olson etcetera file:

    # Zone NAME GMTOFF RULES FORMAT [UNTIL]
    Zone Etc/GMT-11 11 - GMT-11
    Zone Etc/GMT+11 -11 - GMT+11

    Such zic input, specifically the GMTOFF column, uses the usual sign
    convention; you can see here that the zone names use the opposite
    convention.
    Cool, thanks for the clarification.

    I'd hate to think of how much software out there assumes the same as I
    did.
    Does any sane software actually use these ancient time zone names?

    The only useful thing to do is use a zone like America/Chicago so you get
    DST transitions and such. If you want a DST-less zone that's simple to
    understand, you should use UTC, not some fixed offset from UTC (which will
    very confusingsly match up with different local time zones as DST comes
    and goes in various places).


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Alfie John at Dec 5, 2013 at 12:24 am

    On Thu, Dec 5, 2013, at 10:53 AM, Dave Rolsky wrote:
    On Thu, 5 Dec 2013, Alfie John wrote:
    Does any sane software actually use these ancient time zone names?

    The only useful thing to do is use a zone like America/Chicago so you get
    DST transitions and such. If you want a DST-less zone that's simple to
    understand, you should use UTC, not some fixed offset from UTC (which
    will
    very confusingsly match up with different local time zones as DST comes
    and goes in various places).
    I planned on using them as a fallback when the Olson equivalent could
    not be found.

    Alfie

    --
       Alfie John
       alfiej@fastmail.fm
  • Dave Rolsky at Dec 5, 2013 at 5:06 am

    On Thu, 5 Dec 2013, Alfie John wrote:
    On Thu, Dec 5, 2013, at 10:53 AM, Dave Rolsky wrote:
    On Thu, 5 Dec 2013, Alfie John wrote:
    Does any sane software actually use these ancient time zone names?

    The only useful thing to do is use a zone like America/Chicago so you get
    DST transitions and such. If you want a DST-less zone that's simple to
    understand, you should use UTC, not some fixed offset from UTC (which
    will
    very confusingsly match up with different local time zones as DST comes
    and goes in various places).
    I planned on using them as a fallback when the Olson equivalent could
    not be found.
    You might as well just pass an offset directly to DateTime:

        # This is UTC-10
        DateTime->new( ..., time_zone => '-1000' );


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Ken Irving at Dec 5, 2013 at 12:30 am

    On Wed, Dec 04, 2013 at 05:53:02PM -0600, Dave Rolsky wrote:
    On Thu, 5 Dec 2013, Alfie John wrote:
    On Thu, Dec 5, 2013, at 09:40 AM, Zefram wrote:
    Alfie John wrote:
    I guess it's a tautology seeing as that's what's defined in the etcetera
    file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?
    Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see
    this by looking in the Olson etcetera file:

    # Zone NAME GMTOFF RULES FORMAT [UNTIL]
    Zone Etc/GMT-11 11 - GMT-11
    Zone Etc/GMT+11 -11 - GMT+11

    Such zic input, specifically the GMTOFF column, uses the usual sign
    convention; you can see here that the zone names use the opposite
    convention.
    Cool, thanks for the clarification.

    I'd hate to think of how much software out there assumes the same as I
    did.
    Does any sane software actually use these ancient time zone names?

    The only useful thing to do is use a zone like America/Chicago so
    you get DST transitions and such. If you want a DST-less zone that's
    simple to understand, you should use UTC, not some fixed offset from
    UTC (which will very confusingsly match up with different local time
    zones as DST comes and goes in various places).
    This is a point of confusion to me. I manage several research data
    loggers, pretty much all in our local area, and the convention has long
    been to keep them on local 'standard' time, no DST, just a fixed offset
    from UTC. I did end up using the ..::OffsetOnly module on a recent server
    job, but it seems fairly awkward (but works great!) compared to having
    the kind of fixed-offset zones available as described in this thread.

    I do agree for the most part that using UTC on the loggers would be
    simpler to manage, and would definitely go that way if we had deployments
    in other zones, but for now need to support legacy systems using the
    local non-DST zone. I guess that, to me, the ideal solution would be
    to have zones like the 'Etc/' ones, but hopefuly using the less funky
    modern offset sense, if that might be somehow considered for the future.

    I considered using the America/Anchorage zone and then applying a flag
    to disable DST, but that could wreak havoc if DST ended up getting
    un-disabled accidentaly, perhaps sitting there for months before going
    into effect. Having something like UTC-0900 or UTC-9 would seem like
    a simple and non-ambiguous solution.

    Another off-the-cuff thought might be to apply a suffix, e.g.,
    America/Anchorage/noDST, which at least would be explicit in the setting
    and would not have to rely on another step to disable DST.

    Ken
  • Zefram at Dec 5, 2013 at 6:21 pm

    Ken Irving wrote:
    I do agree for the most part that using UTC on the loggers would be
    simpler to manage,
    That's what I'd recommend for any new application.
    the ideal solution would be
    to have zones like the 'Etc/' ones, but hopefuly using the less funky
    modern offset sense,
    If you need a non-zero fixed offset, and must use named zones rather
    than DT:TZ:OffsetOnly, I recommend not worrying about the names.

    If your requirement for compatibility is that you can implement the
    zone as a $TZ value, rather than that you actually use an Olson name,
    another option is an explicit SystemV-style zone specification. You can
    get whatever combination you want of offset and initialism. For example,
    "<UT-09>9" is a valid $TZ value:

    $ date -u; TZ="<UT-09>9" date
    Thu Dec 5 18:18:48 UTC 2013
    Thu Dec 5 09:18:48 UT-09 2013

    DT:TZ doesn't handle this kind of zone specification, but DT:TZ:SystemV
    does.

    -zefram
  • Ken Irving at Dec 5, 2013 at 9:57 pm

    On Thu, Dec 05, 2013 at 06:21:12PM +0000, Zefram wrote:
    If you need a non-zero fixed offset, and must use named zones rather
    than DT:TZ:OffsetOnly, I recommend not worrying about the names.
    I don't need named zones, just want to have the offset in a configuration
    setting. From another response I've reduced the usage in my application to:

       my $tzofs = "-0900"; # ... or read from a config file or constant
       my $tztime = DateTime->now(time_zone=>$tzofs)->strftime("%y:%j:%H:%M:%S");

    This is clearly described in the manual but I had missed it:

       DateTime->now( ... )
         ... Just as with the new() method, it accepts "time_zone" and
         "locale" parameters.

       DateTime->new( ... )
         ...
         The time_zone parameter can be either a scalar... A string will
         simply be passed to the DateTime::TimeZone->new method as its "name"
         parameter. This string may be ... an offset string ("+0630")...

    Thanks for the help and all the work.

    Ken

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedDec 3, '13 at 12:32a
activeDec 5, '13 at 9:57p
posts13
users4
websitemetacpan.org...

People

Translate

site design / logo © 2019 Grokbase