Re: rounder DT:TZ
auta...@urth.org wrote: >the ideal would be to include the zone and the invalid local time in the >message. I've just uploaded DT:TZ:SystemV 0.005 to CPAN, and it does this: $ perl -MDateTime::TimeZone::SystemV -MDateTime -lwe 'print DateTime::TimeZone::SystemV->new(recipe=>"CST6CDT,M3.2.0,M11.1.0",name=>"America/Chicago")->offset_for_local_datetime(DateTime->new(year=>2011,month=>3,day=>13,hour=>2,minute=>30,time_zone=>"UTC"))' local time 2011-03-13T02:30:00 does not exist in the America/Chicago timezone due to offset change at -e line 1 The error message is now very informative. The new option to override the zone name (which was previously always the recipe) will be used by DT:TZ:Tzfile in order to get the right name in this error message. (DT:TZ:SystemV supplies the far-future part of DT:TZ:Tzfile.) New DT:TZ:Tzfile tomorrow. Then DT:TZ:Olson. Then DT:TZ. -zefram
Re: rounder DT:TZ
On Mon, Sep 26, 2011 at 05:45:30PM +0100, Zefram wrote: > Dave Rolsky wrote: > > That information isn't easily accessible on a system in any other > >way that I know of. > > It's supplied in data structures in T:OTZ:D or DT:TZ:Olson. Including the > parts that aren't represented in the old DT:TZ:Catalog data structures. > As I said earlier, it's easy to write code around that to present it > as POD, or in any other human-oriented format. We could provide a > command-line program that wraps that. How easy does it have to be? > > I'd be interested to hear from people who actually use the current > DT:TZ:Catalog document. I use the DateTime::TimeZone::Catalog, as an easy reference so I can see what zones I have installed *on this box*, as opposed to wikipedia-type references that list the various timezones that exist (that may or may not be installed locally, depending on the age of my data). Perl documentation should be available via 'perldoc'. A pod that simply says "run this command to see all installed zones: ..." is fine - just don't take away easy access to my installed zones, or the DateTime::TimeZone::Catalog pod. So, if you're not going to generate a pod that contains this list at build- or install-time, please provide an executable (App::Cmd is nice!) that generates the list on the fly. -- "Martyrdom has always been a proof of the intensity, never of the correctness, of a belief." - Arthur Schnitzler . ... . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
Re: rounder DT:TZ
Dave Rolsky wrote: > That information isn't easily accessible on a system in any other >way that I know of. It's supplied in data structures in T:OTZ:D or DT:TZ:Olson. Including the parts that aren't represented in the old DT:TZ:Catalog data structures. As I said earlier, it's easy to write code around that to present it as POD, or in any other human-oriented format. We could provide a command-line program that wraps that. How easy does it have to be? I'd be interested to hear from people who actually use the current DT:TZ:Catalog document. -zefram
Re: rounder DT:TZ
On Mon, 26 Sep 2011, Zefram wrote: Dave Rolsky wrote: Actually, thinking about this a bit more, I really think it's a good idea to generate it as part of building the distro. That way these docs will be available from metacpan.org and s.c.o. That'll be even more out of date than generating it at install time, if that's done in any distro other than Time::OlsonTZ::Data. I'm not inclined to put it there, because I'm not seeing the value in such a document. Right, so generate it there and just have DateTime::TimeZone::Catalog say "see Time::OlsonTZ::Data::Catalog for a list of all zones". The value is that it provides information on all the zones in various ways. That information isn't easily accessible on a system in any other way that I know of. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: rounder DT:TZ
Dave Rolsky wrote: >Actually, thinking about this a bit more, I really think it's a good idea >to generate it as part of building the distro. That way these docs will >be available from metacpan.org and s.c.o. That'll be even more out of date than generating it at install time, if that's done in any distro other than Time::OlsonTZ::Data. I'm not inclined to put it there, because I'm not seeing the value in such a document. -zefram
Re: rounder DT:TZ
On Mon, 26 Sep 2011, auta...@urth.org wrote: As to how and when these docs get generated, I don't really care, I just want the docs to be available after the distro is installed. If you want to do that as part of the install process that's fine. Actually, thinking about this a bit more, I really think it's a good idea to generate it as part of building the distro. That way these docs will be available from metacpan.org and s.c.o. It wouldn't be too hard to do this with Module::Build or dzil (or Module::Install, I assume). -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: rounder DT:TZ
auta...@urth.org wrote: >I'd like to hear from David Pinkowitz and Olivier Mengue on this. Sure. >I'd be fine with new names for utility subs like this. Obviously there'd have >to be a deprecation period. I'm not intending to ever remove the old interfaces. They're cheap to retain indefinitely. >able DT::TZ without a conflict on an existing DateTime.pm. That's the idea. >When you release the new DT::TZ I'll release a new DateTime.pm >with fixed tests. Ah, I didn't grasp earlier that it was *DateTime*'s test suite that broke. That's a non-trivial issue. You should release the new DateTime straight away, or at least before the new DT:TZ goes out, so that current DT will always install OK with current DT:TZ. There has to be at least one DT version that can install with either flavour of DT:TZ. I think you've said that the current DT is actually OK with new DT:TZ in normal operation; if it were not then we might have to rethink. Changing DT to require new DT:TZ is a later stage which I don't really want to think about atm. >I think the message from TzFile is actually less informative. Heh, apparently we have different priorities. I find the old DT:TZ's message less informative because it doesn't say *why* the local time is invalid (it can also be because the zone was disused) and it doesn't say where in the code the error occurred. >the ideal would be to include the zone and the invalid local time in the >message. Yes, sounds good. If we're OK with changing the messages at all, I'm OK with putting this information into the messages from DT:TZ:Tzfile and DT:TZ:SystemV. (They'll both have to change, because DT:TZ:SystemV is used to implement the far future of tzfile zones.) >First, the module needs to just exist in the new distro. I think people might >be relying on it for docs. If the new distro doesn't replace it then they'll >be left with out of date docs, which is no good. Good point. Should probably have a .pm that doesn't load, containing POD pointing at the current location for the data. >As to how and when these docs get generated, I don't really care, I just want >the docs to be available after the distro is installed. It's tricky if you want that to be a literal installed POD file and want it up-to-date. Would you be happy with the access mechanism being something other than "perldoc $module_name"? It's easy to generate the current style of POD on the fly, just difficult to install it. >Yeah, I think shipping it would be a good idea. You can make a note of it in >the Changes file. OK. >Whatever works for you. As long as it's publicly available and in the distro >metadata, I'm happy. I just don't want the project to become less visible >after you take it over. I'll look into that. >Yeah, that's a good point. I guess I'm fine with not having comaint. OK, cool. -zefram
Time::OlsonTZ::Data 0.201111 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.20.tar.gz size: 214430 bytes md5: 98b00dc30eee4100d4cac8a269db6c2a Time-OlsonTZ-Data-0.20 is based on version 2011k of the Olson database. It contains 439 canonical zones and 142 links. -zefram
Re: rounder DT:TZ
I wrote: >I've got plans for DT:TZ:Local. Another strand of this that might be of interest. I got thinking about the various mechanisms we have that try to DWIM with a ruleless SystemV-style zone spec (such as "GMT0BST"). The Olson database has the main US ones as links to appropriate geographical zones, and also (commented out) another version of them that just implements the US 1976 rules like DT:TZ:SystemV does. AIX and HP-UX both have systems in which the known geographical timezones are named in the SystemV style. DT:TZ has a couple of irregular aliases to Olson zones. In all of these cases, only a handful of zones are supported, and all by manual effort. I'd like to have a systematic approach to this. Given the availability of the entire Olson database, we can look at every zone and pick out its abbreviations and offsets for any particular year we're interested in (or for all years within a broad range). In some cases there will be offset changes that don't fit into the SystemV scheme, but usually you'll be able to generate a ruleless SystemV-style spec that (partially) describes the behaviour of a zone in a particular year. Then, given such a ruleless zone spec, you can emit a list of all the candidate geographical zones. The most conservative potential use of this would be in a timezone selection widget: "you're currently configured for EST5EDT, do you want America/New_York, America/Chicago, ...?". A more advanced usage would be to automatically pick one of the candidates (on what basis I don't know) and either use the zone as a whole or apply its DST rules while staying within the POSIX limits of what the zone spec could mean. This could potentially be useful default behaviour somewhere within DT:TZ. -zefram
Re: rounder DT:TZ
> 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'd like to hear from David Pinkowitz and Olivier Mengue on this. I don't
care
too much about how things are split up, I just want to make sure it's easy
for
them to get updates out to the world at large.
>>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.
I'd be fine with new names for utility subs like this. Obviously there'd have
to be a deprecation period.
The main reason we need DT::TZ->new to work is so that the new DT::TZ distro
is compatible with existing DateTime.pm installations. I'd like people to be
able DT::TZ without a conflict on an existing DateTime.pm.
> 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.
I'm totally fine with "lookup_zone".
>>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.
It can be documented at the end of the docs under a section on deprecated
backwards compatibility code.
>> 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.
Yeah, I fixed the test suite. This isn't a big issue, since installing the
new
DT::TZ won't break an existing DateTime.pm because of this. It just broke the
test suite. When you release the new DT::TZ I'll release a new DateTime.pm
with fixed tests.
>>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.
I think the message from TzFile is actually less informative. Really, I think
the ideal would be to includ
Re: rounder DT:TZ
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 {
