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
