Re: Did April go missing in Asia/Amman?
Bill Moseley wrote: >The code Eric pointed me to sets the hour to 12 on a floating $dt and then >sets the timezone. Sounds like there's cases where that could still fail. Right, that's broken. That's not the algorithm I was proposing. You should search among *UT* times, and the only kind of conversion you need is to represent a given UT time in zone terms, which doesn't run into this problem. There is no need to specify a local time and convert it to UT or otherwise process it. Your initial search range is centred around the UT start of the specified day, with a radius around that centre point of 1440 minutes or so. >This is for a form where a user can enter a start and end date (not a time) >and expect to see all events during those days. i.e. From 2016-04-01 to >2016-04-30. To handle the inclusive upper day boundary, increment the supplied date (calendar arithmetic only, ignore zone behaviour) to get an exclusive upper day boundary. Find the beginning of that day in zone time to get an exclusive upper UT time boundary. >The form's defaults are suppose to be the dates for the *current* start and >end of the month *in the user's time zone*. For this part, you just take the current UT time and represent it in zone terms. That tells you what month to default to. -zefram
Re: Did April go missing in Asia/Amman?
Eric Brine wrote: >I can't figure out how to search only down to the minute without causing it >to find the wrong answer on days with two midnights. In those fairly common cases, where DST ending causes time to jump back from 01:00 to 00:00, you want to consistently get the earlier midnight. This doesn't pose any real difficulty. Finding a UT time that corresponds to local time 00:00 doesn't tell you that you've found the real boundary: it only tells you that the real boundary is no later than this time. You continue the binary search. The criterion you use, to decide which range endpoint to replace with the bisected timestamp, is whether the local time to which it corresponds is greater than or equal to 00:00 on the target day. You should end up with two consecutive UT minutes, the earlier of which precedes the target day in zone time, and the later of which falls on or follows the target day in zone time. The only situation that would really screw up this search is if time jumped back from, say, 00:30 to 23:30, making the span of a calendar date discontinuous in zone time. (Is this what you meant by "two midnights"?) No zone actually does this. While changing the effective length of a local day is quite palatable, making a day discontinuous is too big an inconvenience. Note that this is inconvenient *for people in the zone*, unlike things like there being no local 12:00, which is inconvenient *for programmers* and happens all the time. -zefram
Re: Did April go missing in Asia/Amman?
Eric Brine wrote:
>The binary search found:
...
>2013-11-03T03:45:00 UTC
>2013-11-03T04:07:30 UTC
You should only examine integral minutes. Truncate to the minute
when bisecting, before you pass your bisected time to DateTime. Or,
to avoid fractions entirely, extend the search radius to 2048 minutes.
Either way, do not burden DateTime with any arithmetical job.
Here's an implementation of what I mean:
sub start_of_day {
my($tgt_date_str, $zone) = @_;
$tgt_date_str =~ /\A([0-9]{4})-([0-9]{2})-([0-9]{2})\z/ or die;
my $tgt_date_ut = DateTime->new(year => "$1", month => "$2",
day => "$3", time_zone => "UTC");
my($tgt_date_epoch_min) = $tgt_date_ut->epoch / 60;
my($tgt_date_rd) = $tgt_date_ut->utc_rd_values;
my $left_epoch_min = $tgt_date_epoch_min - 1440;
my $right_epoch_min = $tgt_date_epoch_min + 1440;
while(($right_epoch_min - $left_epoch_min) > 1) {
my $try_epoch_min = ($left_epoch_min + $right_epoch_min) >> 1;
my $try_dt = DateTime->from_epoch(epoch => $try_epoch_min*60,
time_zone => $zone);
(($try_dt->local_rd_values)[0] >= $tgt_date_rd ?
$right_epoch_min : $left_epoch_min) = $try_epoch_min;
}
return DateTime->from_epoch(epoch => $right_epoch_min*60);
}
Use as in:
@ARGV == 2 or die;
my($tgt_date_str, $zone_name) = @ARGV;
my $zone = DateTime::TimeZone->new(name => $zone_name);
print start_of_day($tgt_date_str, $zone), "Z\n";
-zefram
Re: Did April go missing in Asia/Amman?
Eric Brine wrote: >Thanks. I'll study this. I didn't think dividing by 60, adding 60 and >subtracting 60 was safe before of leap seconds. POSIX time, what DateTime calls "epoch" time, doesn't count leap seconds. Each multiple of 60 corresponds to the top of a UTC minute. -zefram
Re: Did April go missing in Asia/Amman?
Eric Brine wrote: >00:00:04 <--- Starting from this You shouldn't be getting such a time at any point in the algorithm I was proposing. -zefram
Re: How to tell (in advance) if a date-time is ambiguous?
Binarus wrote: >So is there any change to add an according API function to DT:TZ? Yes, but we wouldn't want to rush it. There's more than one implementation of the API, and we want to be sure to design it correctly the first time. Perhaps it could be a ->offsets_for_local_datetime method (note plural in the name), which returns a sorted list of all the timezone offsets that are applicable to a specified local time. Normally the list would have length 1, the element being the same value returned by ->offset_for_local_datetime. Ambiguous local times (regardless of the source of ambiguity) yield more than one offset. Non-existent local times (skipped due to clocks going forward) yield an empty list without error. -zefram
Re: How to tell (in advance) if a date-time is ambiguous?
Dave Rolsky wrote: >If you're trying to avoid these, the best advice I could give would be to >avoid the 12am-4am window, which AFAIK is when most (all?) transitions have >occurred historically. Most, but there are both historical and current exceptions. America/Godthab (west Greenland) changes 22:00->23:00 and 23:00->22:00 (base offset -03:00, with transition at 01:00 UT per EU rules). America/Santiago (Chile) changes 00:00->23:00. Pacific/Easter (Easter Island) changes 22:00->23:00 and 22:00->21:00 (changing at the same time as Chile, but with base offset 2 hours to the west). Historically, Africa/Casablanca (Morocco) changed 12:00->13:00 in a DST change in 1967. And Pacific/Kwajalein (part of the Marshall Islands) jumped across the international date line in the unfashionable direction, repeating 23 hours of 1969-09-30. -zefram
Re: How to tell (in advance) if a date-time is ambiguous?
Binarus wrote: >As the documentation tells us, DateTime always chooses the later time >when calculating with ambiguous times, This logic is actually in DateTime::TimeZone, where DateTime invokes it via the ->offset_for_local_datetime method. The internal logic is able to walk the sequence of observances, and when it finds a matching observance it looks ahead to the next one to check specially for ambiguity. It returns the later span if there's an ambiguity due specifically to a change from DST to non-DST; it doesn't have guaranteed behaviour in any other ambiguity scenario. DT:TZ doesn't document this feature, and doesn't offer any other form of ambiguity detection in its API (though of course it would be possible to add some). > and if you subtract an hour from >the later (ambiguous) time, you'll get the same time, but the earlier >one (provided the clock is turned back by an hour when switching back). You can't rely on offset changes, even specifically ones for DST, being of an hour. Australia/Lord_Howe (Lord Howe Island) does a regular half-hour DST jump. -zefram
Re: How to tell (in advance) if a date-time is ambiguous?
Binarus wrote: >Did you memorize the tzfile of 1969 :-) I looked through the Olson source files. I could also have automated a search through the compiled zone data. -zefram
Re: TimeZones and politics Re: How to tell (in advance) if a date-time is ambiguous?
Bill Ricker wrote: >On Tue, Jul 11, 2017 at 4:07 AM, Binarus <li...@binarus.de> wrote: >> and the next law could determine the switch to >> happen at 08:48:27 am, and > >It could in theory, but would be beyond atypical. There have historically been some DST rules calling for changes at 00:01. For example, America/Moncton (New Brunswick, Canada) changed 00:01->01:01 and 00:01->23:01 from 1993 to 2006. The 00:01->23:01 change is particularly unusual for turning the date back. The Olson database also shows some one-off changes (not DST changes) that were not minute-aligned in the previously-prevailing local time, but these are only when changing from local mean time to a UT-based standard time, at a time that's minute-aligned in the new standard time. >(The file format and software should handle 08:48,not sure about 08:48:27 ?) The file format, and all the software I know about, can handle transitions at any second. -zefram
Re: How to tell (in advance) if a date-time is ambiguous?
Binarus wrote: >Using DateTime, is it possible to tell in advance if a certain date-time >which is given in a certain locale will be ambiguous due to switching >from DST to standard time? That is tricky. I don't think our APIs provide any way to do it. Thinking about the facilities available a bit lower down, the way I'd probably approach it is to look at the list of all the offsets ever used in that timezone (not available through any API, but extractable from the tzfile). I'd compute for each the UT time that would be represented by the specified local time with that offset, and then use the regular API to convert that UT time to the local time in the specified timezone (or equivalently just to look up the zone's offset for that UT time). Look at which local times come out matching the specified local time (which offsets match the candidate offset that we were trying). If there's more than one match, that's an ambiguous local time. If there are no matches, it's a non-existent local time. Something close to this can actually be done in the C time API. You don't get to ask what all the zone's offsets are, but in the local->UT conversion you can specify whether DST is in effect. Giving both states of that flag gives you two UT times, which you can then convert back to local to check whether they come out with the same DST flag state. This will work for regular DST changes, but not for offset changes that are unrelated to DST. -zefram
Re: How to check if a DateTime is invalid (again - but this time without using eval)?
Thomas (HFM) Wyant wrote:
>One of the edge cases with eval {} is the possibility that $@ gets
>clobbered before you get your hands on it.
The possibility of it being clobbered by a destructor was fixed in 5.14.
(Destructors that do this are considered buggy, for pre-5.14 perls,
and are individually easy to fix, so the problem is still manageable on
those perl versions.)
-zefram
Time::OlsonTZ::Data 0.201702 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201702.tar.gz size: 721268 bytes md5: e60e2f96eb2c2d501fb4468e5ec8d379 sha1: 8cd2303725b607db99487b31cd934122ef10bd93 Changes from the previous release: * Olson database version 2017b (code 2017b, data 2017b): 386 canonical zones, 208 links * in prebuild, remove implicit . from @INC, for security * in prebuild, work with new PD-with-stated-exceptions notice in the new LICENSE file, and new form of copyright notices that lack the ASCII rendition of the copyright symbol, and copy all files from the Olson distribution that are not listed exceptions or marked as copyrighted * no longer include a Makefile.PL in the distribution * in prebuild, declare required Perl version * correct copyright notice in prebuild -zefram
Re: Time::OlsonTZ::Data 0.201702 announcement
I wrote: >Shortly available from all good CPAN mirrors: > > file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201702.tar.gz I've revived the automatic repackaging which broke back at the 2014h release, nearly three years ago. It originally broke then because the new trend to turn what used to be distinct canonical zones into links brought the count of canonical zones down enough to trip a sanity check that I'd put into the automatic process. I didn't fix it at the time because I had a poor mental state and, with this module only in use for experimental purposes, there didn't seem to be the need. (I would certainly have fixed it promptly if we'd switched DT:TZ over to use it, as we've previously discussed.) The automation rotted further, with changes to the copyright notices, an awkward new make rule, and UTF-8 in one of the files in the Olson distro. That's all fixed now, and I expect to keep the automation up to date from here. -zefram
Re: How to check if a DateTime is invalid (again - but this time without using eval)?
Binarus wrote: >- Most people recommend to "catch the error" DateTime throws when >encountering such date-times, but if I got it right, that always >involves eval, even when using modules like Try:Tiny and the like, so I >don't want to do that. Do this. eval is the right tool for the job. -zefram
Re: How to check if a DateTime is invalid (again - but this time without using eval)?
Eric Brine wrote:
>On Mon, Jul 3, 2017 at 11:11 AM, Thomas Klausner <d...@cpan.org> wrote:
>> I personally don't like Try::Tiny, because it changes how 'return' works
>> inside an eval (well, try)
>
>What difference is there?
I think domm is actually thinking of TryCatch there. Inside an eval,
or Try::Tiny's try, a return expression returns from the eval/try.
Inside TryCatch's try, a return expression ignores the try scope and
returns from whatever it would have returned from without it, usually
from the enclosing subroutine.
$ perl -lwe 'sub z { eval { return 123 }; return 456; } print z()'
456
$ perl -MTry::Tiny -lwe 'sub z { try { return 123; }; return 456; } print z()'
456
$ perl -MTryCatch -lwe 'sub z { try { return 123; } return 456; } print z()'
123
-zefram
Re: Subclassing DateTime?
Thomas (HFM) Wyant wrote: >It seems to me that in at least some such cases subclassing >DateTime would be a better alternative. You've run into the terrible factoring of the DateTime system. All three of the modules you named already suffer from it, but subclassing DateTime would make things worse. For subclassing to be the right answer, the objects of your classes would have to be everything that DateTime objects are, plus something that you're adding. But one of the things that DateTime objects are is Gregorian, which your objects are not. -zefram
Time::OlsonTZ::Data 0.201703 announcement
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201703.tar.gz
size: 737648 bytes
md5: f9c045c0bbcc24f9e5cb9f164884951b
sha1: a1897682fbd3f7ec0d4dfd88c670a5d8694e404a
Changes from the previous release:
* Olson database version 2017c (code 2017c, data 2017c): 387 canonical
zones, 206 links
* in prebuild, work with new form of PD-with-stated-exceptions notice
in the LICENSE file
* in documentation, use four-column indentation for all verbatim
material
* in META.{yml,json}, point to public bug tracker
-zefram
Time::OlsonTZ::Data 0.201805 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201805.tar.gz size: 747739 bytes md5: 23c77b0e3f74758ad1d29e836b4b1dd3 sha1: be3f900c2b8beb518a1eaafa2cec5f178aee81e2 Changes from the previous release: * Olson database version 2018e: 388 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201802 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201802.tar.gz size: 729629 bytes md5: 9599533ff132a3622bc622cbaa7d4d72 sha1: 12044d4b72a6cff5fe19f5985390141183f08b9f Changes from the previous release: * Olson database version 2018b: 388 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201801 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201801.tar.gz size: 728913 bytes md5: d37ff1a893c521afba3d2ef7494af45d sha1: f07f4f450b22c59f7740e70146b9458ef3c343ba Changes from the previous release: * Olson database version 2018a: 388 canonical zones, 204 links * do not bundle non-source files that are included in the Olson database distribution * no longer treat olson_code_version and olson_data_version as distinct values, now that both halves are released in lockstep upstream * in prebuild, handle new kinds of download files -zefram
Time::OlsonTZ::Data 0.201803 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201803.tar.gz size: 730796 bytes md5: 3b8ab43a8f588a532faf40986f825121 sha1: 45a18a0e4747be1396445e01e13d31bf46df25f5 Changes from the previous release: * Olson database version 2018c: 388 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201806 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201806.tar.gz size: 761285 bytes md5: 02ad00dbeb0cd3e8175d7678f062289c sha1: ae3f9ffb9e1b3f2d282bd8b1cd75be9f2ed3ad0a Changes from the previous release: * Olson database version 2018f: 388 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201807 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201807.tar.gz size: 764928 bytes md5: 616ac029cbf91238b8279c15927ef10c sha1: af5f4098a1c4c2e5cd515fa6717fbba1722ba6f5 Changes from the previous release: * Olson database version 2018g: 388 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201808 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201808.tar.gz size: 778286 bytes md5: 6d160f33659c27e788fea6c99821c046 sha1: cc1a48e43bd43ce217a8d4887b422252156db27c Changes from the previous release: * Olson database version 2018h: 389 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201809 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201809.tar.gz size: 778806 bytes md5: 0be3d73258dcc6ce3e695f06fbd7d5c3 sha1: d85dbedca1f4c1a53faccc6c8e3f8a685e3717ef Changes from the previous release: * Olson database version 2018i: 389 canonical zones, 204 links -zefram
Time::OlsonTZ::Data 0.201901 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201901.tar.gz size: 783469 bytes md5: 409c69258d5ed63f134d0f80454baf57 sha1: 2d045e8a27c6444d5b96bc32b59f46da70729566 Changes from the previous release: * Olson database version 2019a: 388 canonical zones, 205 links -zefram
Time::OlsonTZ::Data 0.201902 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201902.tar.gz size: 790741 bytes md5: 13ba3af683256e78610d7198d2a6b097 sha1: 460a25632b34ad6d074b1abbc3537abf2710ec48 Changes from the previous release: * Olson database version 2019b: 388 canonical zones, 205 links -zefram
Time::OlsonTZ::Data 0.201903 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201903.tar.gz size: 799872 bytes md5: 539cef4a4cbba7800a40dd69b5f3b8ea sha1: 0a740049a23a1ffa82161649b63ca645e0a4c540 Changes from the previous release: * Olson database version 2019c: 388 canonical zones, 205 links -zefram
Time::OlsonTZ::Data 0.202001 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202001.tar.gz size: 806724 bytes md5: 076b0e74277f3c40f139fd29b24bbca4 sha1: 07fb6502cf01b0e6f76f2a0d14f36b31f356631d Changes from the previous release: * Olson database version 2020a: 388 canonical zones, 206 links -zefram
Time::OlsonTZ::Data 0.202002 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202002.tar.gz size: 750088 bytes md5: e3c552ce6eaa65d83bd9bc778d93d56c sha1: 2e520e2000c20e9478becfdad496e9751268f065 Changes from the previous release: * Olson database version 2020b: 388 canonical zones, 206 links -zefram
Time::OlsonTZ::Data 0.202003 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202003.tar.gz size: 751008 bytes md5: 9337589dd5ca3482eec4e84e6bdb31d6 sha1: 2c023ee079e93c68ea833b502654eac8ea6f6ea3 Changes from the previous release: * Olson database version 2020c: 388 canonical zones, 206 links -zefram
Time::OlsonTZ::Data 0.202004 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202004.tar.gz size: 752210 bytes md5: 89639f92b77676aa60c46d87ee0462ab sha1: b362be449e0d10d4141fb9553c59da89109f584e Changes from the previous release: * Olson database version 2020d: 388 canonical zones, 206 links -zefram
Time::OlsonTZ::Data 0.202006 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202006.tar.gz size: 765335 bytes md5: a0e9272e175772ac571b9e4c0494dff6 sha1: d4ae70d560979545071e6ac7dff24a0afe90816e Changes from the previous release: * Olson database version 2020f: 387 canonical zones, 207 links -zefram
Time::OlsonTZ::Data 0.202005 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202005.tar.gz size: 765139 bytes md5: 04a8778d23734a86fea8966bab865e72 sha1: c635bb24b2b515268d3a93aad850e94eda20746b Changes from the previous release: * Olson database version 2020e: 387 canonical zones, 207 links -zefram
Time::OlsonTZ::Data 0.202101 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202101.tar.gz size: 765257 bytes md5: 87d3365828cc874464e4da79dee03f4d sha1: ba94229fb25886df0025540c4ae8b61a3853e8e0 Changes from the previous release: * Olson database version 2021a: 387 canonical zones, 207 links -zefram
Time::OlsonTZ::Data 0.202102 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202102.tar.gz size: 781095 bytes md5: 89f437d5b14e666994009f46efbacb23 sha1: 642e5fc40d039d8d76a03c31c37ed30ad9716b9c Changes from the previous release: * Olson database version 2021b: 378 canonical zones, 217 links -zefram
Time::OlsonTZ::Data 0.202301 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202301.tar.gz size: 815719 bytes md5: f56223e008a3fac5204f1397b422df23 sha1: b825d51ea304834f5d2fb827260aa67e70fff1f6 Changes from the previous release: * Olson database version 2023a: 351 canonical zones, 246 links -zefram
Time::OlsonTZ::Data 0.202302 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202302.tar.gz size: 816095 bytes md5: 59b8490bbf0eca46ce597a15f9d0b555 sha1: 779b9933c8c4256e670d389f23ac9ddcb0fdcc33 Changes from the previous release: * Olson database version 2023b: 351 canonical zones, 246 links -zefram
Time::OlsonTZ::Data 0.202303 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202303.tar.gz size: 817161 bytes sha256: 6228e749b7c0509c023fe2b20991ad134c79ab4fcf5ae7d8fcfa536535a1f08c Changes from the previous release: * Olson database version 2023c: 351 canonical zones, 246 links -zefram
Time::OlsonTZ::Data 0.202304 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202304.tar.gz size: 828180 bytes sha256: 6840f0b6b9c53405632a443c86a5d6b362b47a151a5934316c0e864d3d07aff0 Changes from the previous release: * Olson database version 2023d: 352 canonical zones, 245 links -zefram
Time::OlsonTZ::Data 0.202401 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202401.tar.gz size: 830162 bytes sha256: 2b20e5053cb67512c704d6e712289a99c1c5d4003f57b34e21fb6152e1a1969f Changes from the previous release: * Olson database version 2024a: 352 canonical zones, 245 links -zefram
