Dave Rolsky wrote:
>Why borg the Windows and HP-UX code into this distro instead of letting
>other maintainers handle this?
I don't think there's significant value in having separate distros here.
Having a single distro has the distinct advantages that the behaviour
is consistent: you just install the one distro, and its behaviour isn't
affected by whether you installed another one. It also ultimately gives
a conceptual consistency across platforms, by having one person apply a
single philosophy to each platform. The only real advantage of separate
distros is to make it easier for platform-specific developers to work
on their own platform's code, but in the single-distro system they can
still submit patches to the single maintainer.
I've got plans for DT:TZ:Local. It was the most interesting part of the
distro to work on. Collecting the knowledge of how various platforms
natively process timezones is a project reminiscent of the Olson project
to collect knowledge about the civil timezones themselves. The obvious
form in which to deliver the collection of platform-specific knowledge
is the DT:TZ:Local module. I'd also like to add more interfaces
here, so that (for example) you could ask "how would AIX interpret
TZ=GMT0BST?" while running on HP-UX. Even the Windows logic can mostly
run on other platforms; the only truly Windows-specific part of it is
to actually pull the configuration from the registry.
>As far as not automatically recognizing new OS-specific distros, that's
>fine since a new distro is an incredibly rare event.
Ah, you're getting at the consistent-behaviour part. Within the
single-canonical-distro system, there *is* room for subparts to be broken
out into separate distros that are actual dependencies of the top-level
distro. DT:TZ:Local itself seems like a sufficiently large project that
it probably ought to be a separate distro from DT:TZ, but my intention
is to wait until after the switch to new-form DT:TZ before doing that.
I've got a fairly concrete intent to implement parsing of HP-UX's tztab,
which would naturally be a separate distro DT:TZ:Tztab which would then be
a dependency of DT:TZ:Local. Possibly a platform-dependent dependency.
I'd be open to other people doing distros for things such as parsing
the Windows zone database, if I don't get to that first.
>If you want to document DateTime::TimeZone as not a class, I think having
>a documented "DateTime::TimeZone::new" function is really weird.
Yeah, it's a bit odd. I've just left the names the same, so they're all
named from the point of view of class methods. "is_valid_name" is a poor
standalone function name; it should be "is_valid_zone_name" or something.
I didn't want to invent more new stuff than necessary initially.
If we're going to have proper function names, I think we should go
the whole way and make them exportable too. I think just "new" and
"is_valid_name" should have this treatment, because the other functions
are just additional ways of accessing functionality that really belongs
elsewhere. For "new" I prefer the name "lookup_zone" over "load_zone",
because there's caching and so on involved, so it's not necessarily
actually loading anything.
>Obviously, the old DT::TZ->new behavior would need to work too, but it
>doesn't need to be documented, and once this code is released, I can
>adjust DateTime.pm to use the new APIs.
I think if it's to be supported indefinitely (which it must be) then it
needs to be documented, but it doesn't need to be recommended. It can
be explicitly deprecated, along with the catalogue and offset functions.
> One of them was clearly a bug in the
>test suite (expecting 0 for a boolean instead of any false value).
Where functions were documented to return truth values, I presumed
that any truth value would be acceptable. DT:TZ:Alias is different:
it documented that it returns 1 or undef, so I preserved that behaviour.
> but the other failures seem to come from a change in
>an exception's error message.
I felt fairly free about the details of error messages, and so didn't
attempt to replicate any of the old ones. They're not documented,
after all. Some of the old ones are really bad, like "Invalid offset"
when a zone name has unrecognised format. It's quite correct that the
test suite checks that the error message generated is the one that the
code intends to emit, but in checking that I think it's checking more
than the API guarantees.
>The exception that's thrown for an invalid local time is different with
>this new version of the library.
That'd be from DT:TZ:Tzfile. I think you're referring to this difference:
$ perl -MDateTime::TimeZone -MDateTime::TimeZone::Olson -MDateTime -we '$dt =
DateTime->new(year=>2011,month=>3,day=>27,hour=>1,minute=>30,time_zone=>"UTC");
foreach my $z (DateTime::TimeZone->new(name=>"Europe/London"),
DateTime::TimeZone::Olson::olson_tz("Europe/London")) { eval {
$z->offset_for_local_datetime($dt) }; print $@; }'
Invalid local time for date in time zone: Europe/London
non-existent local time due to offset change at -e line 1
It's possible that something's depending on the exact format of the old
DT:TZ error message, and it's also possible that something's depending
on the exact format of the DT:TZ:Tzfile message. I'm not really happy
about changing DT:TZ:Tzfile here, especially since its error message is
more descriptive and better punctuated than the old DT:TZ one.
I did wonder a bit, while writing the new DT:TZ, whether the spelling of
error messages would be a compatibility issue. (I didn't think about
it for the specific message discussed above, since that was ages ago
in a different distro, which backward compatibility wasn't a concern.)
I came to the conclusion that I'd like to see whether any real code
actually broke because of it. It's difficult to decide what lengths we
should go to for backcompat without having any information of that nature.
>The DateTime::TimeZone::Catalog module needs to exist, if only for
>documentation purposes.
Looking at where your line of questioning goes, it looks like you're
referring to having the list of timezones in the documentation. I don't
think this belongs in documentation, being volatile data. I'm not happy
about the idea of generating such a document in T:OTZ:D. I think if you
want to make this readily visible it would be better to ship code that
will generate the POD from the underlying data that it gets from T:OTZ:D.
(Actually, like the catalogue functions in the new DT:TZ, it ought to
get the data from DT:TZ:Olson, which provides another interface to the
data in T:OTZ:D, for modules that are thinking at a higher level.)
>Are there are any 32/64 bit issues we need to deal with?
There's no Y2038 problem. T:OTZ:D always provides the 64-bit form of
tzfiles, and DT:TZ:Tzfile always handles them. We discussed this a long
time ago; one of the motivations for switching to DT:TZ:Tzfile was that
the existing DT:TZ had crap performance for times thousands of years in
the future.
>What happens if a user on a 32 bit system with a 32 bit Perl installs the
>Time::OlsonTZ::Data distro and tries to create a DateTime 100 years in
>the future in the America/New_York zone? I'm guessing it just works, but
>I'd like to know that for sure ;)
It just works:
$ perl -V:'i(v|nt)size'
intsize='4';
ivsize='4';
$ perl -MDateTime::TimeZone::Olson -MDateTime -lwe '$dt =
DateTime->new(year=>2111,month=>9,day=>26,hour=>11,time_zone=>DateTime::TimeZone::Olson::olson_tz("America/New_York"));
print $dt->strftime("%F %T %z"); $dt->add(months=>2); print $dt->strftime("%F
%T %z");'
2111-09-26 11:00:00 -0400
2111-11-26 11:00:00 -0500
There'll be a bit of an issue where the RDN exceeds the range of 32-bit
integer arithmetic, in about 11.8 million years. Existing DT:TZ would
throw a fit (well, eat a lot of memory) with that sort of date. I can
beef up DT:TZ:Tzfile for that if you're worried, but I suspect DateTime
itself would also break at that point.
>I think it also needs some docs on what's changed from an end user
>perspective. The big one is that in order to get Olson updates, the user
>now need to keep track of the Time::OlsonTZ::Data distro, not DT::TZ.
That should be documented, yes. We also ought to talk to the Debian
packaging folks about getting the volatile-data treatment for T:OTZ:D.
>The COMPAT document you attached is good, but it's missing this key point.
I was wondering if COMPAT should be included in the distro, to help
DT:TZ API users with the transition. What do you think?
>I'd really like to see this code in a public repo before it's released,
>along with the various other modules this depends on.
Hmm. I really ought to get on with switching my personal projects to git.
I've been putting that off for ages.
I have my own public git server. I looked at github recently, and I
can't accept its terms of service (and neither should you).
>As far as maintenance, I would like to have comaint, although I'm not
>sure how much good that will really do me since all the real work is done
>in other distros anyway. But it'll make me feel better ;)
I also have difficulty imagining how it would be useful, but I have
little experience with this. One other person has co-maint on one of
my modules, the first one that I span off from $ork, and he's never
used it. If I drop off the net for an extended period without making
maintenance arrangements, you can always go the takeover route, and
you could probably get a fast-tracked co-maint that way if there were
something requiring immediate attention. So I don't see any situation
where you'd validly use co-maint that you have only via this handover
arrangement, but I can't sensibly deny it.
-zefram
