First, I have to say again that the current design of DT::TZ::HPUX is
due to the fact the the author (myself) knew that he would not be able
to maintain this published code up to date (for timezone name mapping)
due to his lack of access to HPUX platforms for a longer time.
So, this is a best effort towards a distribution that can self-update.
Le 2011-05-16 15:32:07, zefram@fysh.org a écrit :
Show quoted text> dependencies
> ------------
>
> DT:TZ:HPUX logically consists of two parts, which have distinct
> dependencies. Firstly, there is the conversion from HPUX $TZ values
> to Olson zone names, which is essentially _hpux_to_olson() minus
> its last line. This code does not have any dependency on DT:TZ.
The current implementation delegates to Java at runtime to query the
mapping for TZ names which were not resolved at install time.
This is clearly dependent on the fact that we are running on a HPUX
system with a JVM able to translate timezone names.
Show quoted text> It is, unfortunately, only operable on the HPUX platform, due to
> its implementation strategy of querying the platform. I call this
> "unfortunate" because the operation of translating an HPUX zone name to
> the corresponding Olson zone name is meaningful independent of platform.
This mapping is something that has to evolve in time. I knew I could not
maintain this.
That's why the current implementation tries to do its best to take
advantage of the tools installed on the platform to discover what is
missing from the distibution built-in table at build time (see JavaMap.PL).
Show quoted text> The second part of DT:TZ:HPUX is the ->new code, which trivially wraps the
> name translation to provide a DT:TZ-like constructor interface. This part
> depends on DT:TZ at runtime. I think you could get some benefit, and
> ameliorate the dependency issue, by separating out these two halves.
>
> I note that DT:TZ doesn't actually use DT:TZ:HPUX at all. Logically there
> is no dependency here, and your problem comes from falsely declaring
> a dependency. The relationship here is more in the nature of a
> *recommendation* than a dependency.
What uses DT::TZ is JavaMap.PL which is used to extract the mapping
table from Java.
Show quoted text> functionality
> -------------
>
> DT:TZ:HPUX strikes me as a poor design in several respects. Firstly, the
> collection of static data at install time. This means that installations
> of the same version of DT:TZ:HPUX can differ from each other.
The system administrator is allowed to add its own data to
/usr/lib/tztab (this data could also come from HP patches). The bigger
plan was to be able to parse the tztab file.
Show quoted text> If static
> data is appropriate, it would be better to run the Java-based extraction
> process offline, and put the resulting data into the CPAN package.
This would require permission to redistribute the data. But who should I
ask for? I prefer to avoid those kind of copyright issues.
Also, if /usr/lib/tztab is updated with new TZ and Java is updated with
new mapping, the user of DT::TZ::HPUX only have to reinstall the
distribution to get the update without requesting an update from the
CPAN maintainer. An update that I could not provide, not having access
to an HPUX environment.
So, this is a feature of the distribution.
Show quoted text> This would remove the dependence on the HPUX platform, so that the module
> can be installed on any platform.
I would be interested in a use case for that.
Show quoted text> Secondly, though I don't have an HPUX machine to test against, the
> builtin map entries in JavaMap.PL suggest that the $TZ format is not
> some HPUX-specific magic after all, but rather the System V style of
> $TZ value as enshrined by POSIX. This $TZ format is implemented by
> DateTime::TimeZone::SystemV. That module might be all that's needed
> on HPUX. The POSIX standard leaves open the question of what the DST
> transition dates should be when they're not explicitly stated in the $TZ
> value, and if HPUX is doing something clever there then DT:TZ:SV won't
> be enough.
Yes, HPUX is doing something clever.
This article has some details about hpux:
http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html
It says that POSIX doesn't enforce any standard values in the TZ value,
so the operating system is free to interpret it like is wants: the libc
only has to know what it means. HPUX uses the /usr/lib/tztab file.
Here is an example tztab:
http://pete.gulotta.name/Useful%20Documentation/tztab.htm
And about the "System V" mapping, AFAIK there is no such mapping in
DT::TZ and I had no motivation for maintaining TZ mapping forever.
If I remember well, there were also some issues with some characters
which were used in /usr/lib/tztab names which were conflicting with some
DT::TZ features, so it was not possible to simply add the mapping table
to DT::TZ.
Show quoted text> In that case you'll still want to convert to Olson names, but
> the problem should be reformulated as guessing what Olson zone is meant
> by a *System V style* $TZ value, which is not a problem specific to HPUX.
Java on hpux provides a mapping to OlsonDB, and I solved the issue by
using that mapping.
As I said above there are HPUX specific issues. And not having access to
HPUX systems anymore adds to the complexity of the task.
--
Olivier Mengué -
http://search.cpan.org/~dolmen/ http://github.com/dolmen/
