Re: rounder DT:TZ

Olivier Mengu? wrote:
>- I published the HPUX distro in 2009 just a few weeks before losing access
>to an HP-UX system:

Bummer.  Fortunately there are people around with access who I can bug.
Tux does HP-UX smokes, and would probably be willing to run probe code
for me.

>- the current dependencies between DT::TZ and DT::TZ::HPUX are a mess: see
>https://rt.cpan.org/Public/Bug/Display.html?id=68231

Ah, that is a significant problem of the old DT:TZ arrangement.  But even
without rolling DT:TZ:HPUX into the DT:TZ distro, the way I already have
distros separate solves this problem.  DT:TZ:HPUX can do its job using
DT:TZ:Olson, not requiring the top-level DT:TZ.  The DT:TZ:Local in my new
DT:TZ does exactly that, and so doesn't need to load the DT:TZ module.
There are no circular dependencies between modules in the distro.
(DT:TZ and DT:TZ:Alias have a funny relationship, but I managed to
arrange for neither of them to load the other.)

>This feature in the previous DT:TZ::Local was helpful to allow me to create
>the separate HPUX distribution in the first place, and do that quickly
>without waiting for a patch or an official release.

You could have locally patched DT:TZ:Local, for development purposes.
You could also have invoked your DT:TZ:HPUX directly in the code
that constructs DateTime objects, replacing 'time_zone => "local"'
with 'time_zone => DateTime::TimeZone::HPUX::whatever()'.  For a very
occasional requirement this doesn't seem excessively onerous.

>Please note that one important feature of the DT::TZ::HPUX is that it is
>able to map HPUX timezone ids to Olson ids. This is really helpful to make
>portable applications that rely only on Olson ids.

Right.  There are two fundamentally different approaches to the
DT:TZ:Local concept: exactly match platform behaviour, or guess the
most appropriate real timezone given locally-available clues.  Both are
valuable: the first for interoperability with native software, the second
for interoperability with the world at large.  I already talked about
the latter case a bit wrt SysV-style zone recipes, but it applies just
as well to tztab: we should be able to parse tztab just like HP-UX does,
but we should also be able to look at an HP-UX system with TZ=GMT0BST and
say "ah, you really want Europe/London".  I'm not sure which behaviour
'time_zone => "local"' ought to invoke.  DT:TZ:Local hasn't so far been
precise enough to distinguish between the two philosophies.

Thanks for your comments.

-zefram