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
