Time::OlsonTZ::Data 0.202402 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202402.tar.gz size: 837515 bytes sha256: 7da594b6f6417b8421415c23a56d838c89ce4843f11b58c25b7d316bdaf08bc3 Changes from the previous release: * Olson database version 2024b: 340 canonical zones, 257 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
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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.201804 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201804.tar.gz size: 744089 bytes md5: ac447c9f87f40efc752e3216be72839f sha1: 3d7e1b484ce461ae42d5fd15bf393fb6868b6227 Changes from the previous release: * Olson database version 2018d: 388 canonical zones, 204 links -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.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.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
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
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: 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: 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 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: >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: 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?
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: >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
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 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: 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: 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
Re: Recurring set does not correctly calculate dates for second Friday of the month.
Andrew Martin wrote: >however 17-02-2017 is the Third Friday, the expected result is 10-02-2017 DateTime::Event::Recurrence->monthly doesn't really do "the Nth Fooday of each month". It gives you either "the Fooday of the Nth week that is mostly contained in each month" or "the Fooday of the Nth week that started in each month". Its idea of a week always starts on a specified day of the week; the first week that is mostly contained in a month may start on any day from three days before the 1st of the month up to the 4th of the month. You *can* use this to get the Nth Fooday of each month, by manipulating how the weeks are delimited. Observe that each week is mostly contained in the month that contains its fourth day. If you're only interested in which month contains a specific day of the week, you just have to arrange for that day to be the fourth of the week. So to get the Nth Friday of each month, you need to tell it that the week starts on Tuesday: my $set = DateTime::Event::Recurrence->monthly(weeks => 2, days => "fr", week_start_day => "tu"); Or you can use weeks starting in the month, and tell it that the day you're interested in is the first day of the week: my $set = DateTime::Event::Recurrence->monthly(weeks => 2, days => "fr", week_start_day => "1fr"); The example in the module's documentation labelled "second tuesday of every month" is incorrect. It actually yields Tuesdays ranging from the 9th to the 15th of each month, because it is computing the Tuesdays of the second week to start in each month, with the week starting on Monday. -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:
>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: >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: 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?
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?
Bill Moseley wrote: >hour=> 12, # Assume this exists This does not always exist. Africa/Khartoum on 2000-01-15, for example. In fact, thanks to cases such as Pacific/Apia on 2011-12-30, not only is there no hour that exists on every day in every zone, there are actually some zone days for which no hour exists. >And for the end time of the month (to the second): Rather than subtract a second and use a <= comparison, it's cleaner to use the start time of the next month and a < comparison. >I was thinking of an implementation that assumed DST change happened at an >hour boundary and simply try incrementing hours until no more exceptions. That's a bad assumption. You can assume *minute* boundaries, but not hours. -zefram
Re: Did April go missing in Asia/Amman?
Bill Moseley wrote: >In other words, I'm trying to find the start and end times for the current >month based on a given timezone and then use those in my database query. You can perform a binary search on UT times, looking for the boundaries where the month changes in zone time. For each month boundary, start with a range of the UT month boundary plus and minus 24 hours. 18 steps of binary search gets you down to the second, but actually modern zones are always on integral-minute offsets, so you could look only at integral minutes and take only 12 steps. For each UT time you try, convert it to zone time and see which month it ends up in. -zefram
Re: Did April go missing in Asia/Amman?
Bill Moseley wrote: >Why can't I truncate to the month? Because 2016-04-01T00:00:00 didn't exist in Asia/Amman. Its DST rules include a switch from winter time to summer time at 24:00 on the last Thursday in March. This has the effect of skipping the hour from 00:00 to 01:00 on some Friday morning. This year the last Thursday in March was the last day in March, so the affected Friday was the first day of April. -zefram
Time::OlsonTZ::Data 0.201407 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201407.tar.gz size: 665182 bytes md5: b999f49116bedeecab69e1c9bad98282 Changes from the previous release: * Olson database version 2014g (code 2014g, data 2014g): 405 canonical zones, 177 links -zefram
Time::OlsonTZ::Data 0.201406 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201406.tar.gz size: 649615 bytes md5: a1e6af771fe58f17a0c03636c3da0725 Changes from the previous release: * Olson database version 2014f (code 2014f, data 2014f): 414 canonical zones, 168 links -zefram
Time::OlsonTZ::Data 0.201405 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201405.tar.gz size: 648447 bytes md5: 9357d0d7f12e824127a49388a62363cd Changes from the previous release: * Olson database version 2014e (code 2014e, data 2014e): 425 canonical zones, 155 links -zefram
Time::OlsonTZ::Data 0.201404 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201404.tar.gz size: 647631 bytes md5: 40c7149d5a261553e6c13af57b84416c Changes from the previous release: * Olson database version 2014d (code 2014d, data 2014d): 425 canonical zones, 155 links -zefram
Time::OlsonTZ::Data 0.201403 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201403.tar.gz size: 646013 bytes md5: 17909ab88ec08fad82d5728c75d19ff1 Changes from the previous release: * Olson database version 2014c (code 2014c, data 2014c): 425 canonical zones, 155 links * declare correct version for Test::More dependency -zefram
Re: Dear All, i have got some error. Please help me
>my $dt1 = DateTime->new( >year => 2014, >month => 3, >day => 30, >hour => 3, >minute => 30, >second => 0, >time_zone => 'Europe/Kiev',); > >return an error "Invalid local time for date in time zone: Europe/Kiev". The error message is correct: there is no 03:30 in Kiev time on 2014-03-30. Kiev switched from UT+2h to UT+3h at 01:00 UT, jumping from 02:59 to 04:00 local time. >I have datetime, stored in "UTC" and have some periodical task (period 1 day). >Then i have a customer - for him information must be viewed in??'Europe/Kiev'. This part is no problem. Each UT time corresponds to a definite Kiev local time; you can always perform this conversion. The code that you quoted doesn't perform conversion; you need to create a DateTime with time_zone=>"UTC" and then set_time_zone. >But he want that task will execute in 00:03:30 in his local timezone. Presuming you mean at 03:30, this is not possible for Kiev on 2014-03-30. In general, it is not possible to do something at a fixed local time every day; there's always some day and locality for which that local time doesn't exist. In the extreme, there are cases such as Christmas Island (Pacific/Kiritimati) on 1995-01-01, where local time skipped the entire calendar day as the island switched from the eastern side of the International Date Line to the more fashionable western side. You must select some alternative behaviour to follow on days when the desired local time doesn't exist. -zefram
Time::OlsonTZ::Data 0.201402 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201402.tar.gz size: 647194 bytes md5: 8926e5c7bb441ef37a394664bf6452a0 Changes from the previous release: * Olson database version 2014b (code 2014b, data 2014b): 425 canonical zones, 155 links -zefram
Time::OlsonTZ::Data 0.201401 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201401.tar.gz size: 644845 bytes md5: eb18772b27091fc69e20ccf07a00e430 Changes from the previous release: * Olson database version 2014a (code 2014a, data 2014a): 424 canonical zones, 155 links -zefram
Re: First time of the day
Eric Brine wrote: >I posted a solution here: >http://stackoverflow.com/a/20850899/589924 That message states |On the DateTime mailing list, Zefram suggested I do a binary search on |the time zone data. The following is an implementation of that solution: which is not correct. I did not suggest searching among observance spans, as the code there does. I suggested searching among UT times. Please post a correction. >I perform a binary search of the tz's spans, looking at the *local* times. This is a valid approach *if* you have access to the span data itself. The code you posted on stackoverflow uses the internals of the current DT:TZ implementation. The public API for DT:TZ objects doesn't support this. That's (in part) why I suggested an algorithm that only accesses zone data in the form of UT->local conversions. >*I made one assumption*: There is no dt to which one can add time to obtain >a dt with an earlier date. That's the same assumption I made, which I reckon is justified by the Olson database. -zefram
Re: First time of the day
Eric Brine wrote: >Given a date and time zone, is it possible to obtain the first time of that >date? Given standard APIs for time conversion, I'd perform a binary search among UT times, converting them to the zone's local time and looking for the threshold at which the local date changes. The result of the conversion at the threshold time includes a local time-of-day that should be the one you're after. This search approach assumes that all the UT times associated with a particular local date are contiguous, which I think is the case throughout the database, even in extreme cases. (The most extreme cases are zones such as America/Anchorage that crossed the IDL from a positive UT offset to negative, yielding a period of 48 consecutive hours associated with a single calendar day in local time. Though in the specific case of Alaska the single calendar day is conventionally described using different calendars for the two halves of that 48-hour period.) Another type of edge case also might matter, depending on what you mean by "the first time of that date". If you actually want the local time-of-day at the beginning of the calendar day, that's fine. But if you actually want the lowest local time-of-day that occurs at any time during the calendar day, you could in principle be misled by a zone that jumps forward at midnight and then back slightly later (say, forward an hour at local 00:00->01:00, then back an hour at local 01:30->00:30). I think this also doesn't occur anywhere in the database. -zefram
Time::OlsonTZ::Data 0.201309 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201309.tar.gz size: 642225 bytes md5: d1007a1050fd17a99bb2cfc18d214517 Changes from the previous release: * Olson database version 2013i (code 2013i, data 2013i): 424 canonical zones, 155 links -zefram
Re: DateTime::TimeZone and etcetera zones
Ken Irving wrote: >I do agree for the most part that using UTC on the loggers would be >simpler to manage, That's what I'd recommend for any new application. > the ideal solution would be >to have zones like the 'Etc/' ones, but hopefuly using the less funky >modern offset sense, If you need a non-zero fixed offset, and must use named zones rather than DT:TZ:OffsetOnly, I recommend not worrying about the names. If your requirement for compatibility is that you can implement the zone as a $TZ value, rather than that you actually use an Olson name, another option is an explicit SystemV-style zone specification. You can get whatever combination you want of offset and initialism. For example, "9" is a valid $TZ value: $ date -u; TZ="9" date Thu Dec 5 18:18:48 UTC 2013 Thu Dec 5 09:18:48 UT-09 2013 DT:TZ doesn't handle this kind of zone specification, but DT:TZ:SystemV does. -zefram
Re: DateTime::TimeZone and etcetera zones
Alfie John wrote: >I guess it's a tautology seeing as that's what's defined in the etcetera >file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11? Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see this by looking in the Olson etcetera file: # Zone NAMEGMTOFF RULES FORMAT [UNTIL] ZoneEtc/GMT-11 11 - GMT-11 ZoneEtc/GMT+11 -11 - GMT+11 Such zic input, specifically the GMTOFF column, uses the usual sign convention; you can see here that the zone names use the opposite convention. -zefram
Re: DateTime::TimeZone and etcetera zones
Alfie John wrote:
> If it doesn't aim to have mappings to all of
>the Olson entries is there a reason not to provide mappings with my
>patches?
Dave Rolsky can answer better about the design intent. But there's
a practical issue with changing right now: we're in the process of
transitioning to a reimplementation of DT:TZ. Current state is that the
new DT:TZ is ready, but DateTime has reacquired an over-sensitive test
(of a type we fixed one instance of some time ago) that looks at timezone
error messages and fails against the new DT:TZ.
The new DT:TZ is based on DT:TZ:Olson, and it passes things not explicitly
overridden through to DT:TZ:Olson. I believe this means it will accept
Etc/GMT+10 and the like, with the Olson meaning. This difference
isn't actually listed in the upgrading notes, which seems an oversight.
(The upgrading notes do mention the Factory zone.)
>I unfortunately need exact mappings,
So you also won't like DT:TZ's other deviations from Olson. DT:TZ uses
Olson data to provide some of its zones, but its objective is broader and
more nebulous than just providing access to the Olson data. DT:TZ:Olson,
on the other hand, has the sole intention of providing access to the
Olson database.
>looks like there's a bug (POSIX sign flipping which I've fixed in my
>patch to DateTime::TimeZone):
I believe you're mistaken about the bug. (It seems to be a firm rule
that everyone working with timezones gets the sign wrong occasionally.)
Looking at your test case:
> print "$dt\n";
> $dt->set_time_zone(olson_tz("Etc/GMT+10"));
> print $dt,"\n";
You've started with a DateTime in UT, and asked for it to be reexpressed
in the Etc/GMT+10 zone, which (due to the strange sign convention) is a
fixed ten hours *behind* UT. So I would expect the second time emitted
to be ten hours earlier than the first one, as seen in your
>Actual output:
>
> 2013-12-03T23:39:11
> 2013-12-03T13:39:11
You can also see this behaviour with date(1), on a platform where libc
uses the Olson mechanism:
$ TZ=UTC date -d '2013-12-03T23:39:11Z' +%FT%T%:z
2013-12-03T23:39:11+00:00
$ TZ=Etc/GMT+10 date -d '2013-12-03T23:39:11Z' +%FT%T%:z
2013-12-03T13:39:11-10:00
Also compare with a geographical zone that is ten hours behind UT:
$ TZ=Pacific/Honolulu date -d '2013-12-03T23:39:11Z' +%FT%T%:z
2013-12-03T13:39:11-10:00
$ perl -MDateTime::Format::ISO8601 -MDateTime::TimeZone::Olson=olson_tz -lwe
'$dt =
DateTime::Format::ISO8601->parse_datetime("2013-12-03T23:39:11")->set_time_zone("UTC");
print $dt; $dt->set_time_zone(olson_tz("Pacific/Honolulu")); print $dt;'
2013-12-03T23:39:11
2013-12-03T13:39:11
Internally, DT:TZ:Olson uses the tzfiles generated by Olson zic, and
makes no attempt to interpret the zone names specially. So it would be
essentially impossible for it to have a bug specific to the Etc/ zones.
FWIW, the sign flipping in the Etc/ zone names is the product of a
misunderstanding. The `POSIX' sign flip applies to SystemV-style zone
specifiers, which are standardised in POSIX. (See DT:TZ:SystemV for
Perl implementation.) In that system, for example, "XYZ+10" means the
timezone is a constant ten hours behind UT, and refers to this time by
the initialism "XYZ". So you could sensibly describe it (outside the
POSIX context) as "XYZ = GMT-10". A timezone name "GMT+10" is *not*
using the SystemV format: it's referring to a zone that's offset from
GMT, not something that uses the initialism "GMT". So flipping the sign
there doesn't make sense.
The history of this is partly tied up with the switch to hierarchical zone
names, because "Etc/GMT+10" doesn't clash with SystemV format, but the
old "GMT+10" (which Olson used to have) did clash. Oslon used to have
"GMT+10" meaning ten hours *ahead* of UT, the sensible sign convention,
but the opposite of the offset you'd get from the SystemV specification
with which it clashed. This could be sensibly resolved either by
flipping the signs to match SystemV or by making the names non-clashing.
The Olson folks did both, leading to a ridiculous arrangement.
-zefram
Re: DateTime::TimeZone and etcetera zones
Alfie John wrote: >I had a bit of trouble using timezones defined in the Olson etcetera >data file. DT:TZ intentionally doesn't support them. It's not aiming to provide precisely the semantics of the Olson database, and you'll see they're not listed in DT:TZ:Catalog. If you want to resolve zone names exactly as in the Olson database, use DateTime::TimeZone::Olson (a separate distribution). If you want timezones of fixed offset, prefer DateTime::TimeZone::OffsetOnly over the Olson Etc/ names. -zefram
Time::OlsonTZ::Data 0.201308 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201308.tar.gz size: 666258 bytes md5: bb41c9631003dc66b95c773efe09da3b Changes from the previous release: * Olson database version 2013h (code 2013h, data 2013h): 427 canonical zones, 158 links -zefram
Time::OlsonTZ::Data 0.201307 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201307.tar.gz size: 664500 bytes md5: 5f6d1a60b22e72d6b76a6477dcd9afdf Changes from the previous release: * Olson database version 2013g (code 2013g, data 2013g): 427 canonical zones, 158 links * in prebuild, work with new PD-unless-otherwise-stated notice in the Olson README file, and copy all files from the Olson distribution that are not marked as copyrighted -zefram
Re: 1) Datetime website 2) recommended practice to alter API
Jean Forget wrote: >-- how much time should pass between two steps? In situations like this, I'd accept the old keyword forever, never even making it warn. The ability to use the clearer keywords is a desirable feature, but not a good reason to make the original keywords stop working. >-- in step 1, should the module emit a warning if both keywords >are used at the same time? (I think yes) It should be a hard error, generating an exception, not a warning. >Another question is: which is the earliest Perl version >should we target? Depends on the target audience. You shouldn't go to extra effort to support anything earlier than around 5.12 unless you have a specific user who can't upgrade Perl. Targeting earlier than 5.6 is a pain because the "our" keyword isn't available earlier. Personally I routinely test my CPAN modules against almost all versions back to 5.6.1, but I'm unusual in that regard. -zefram
Time::OlsonTZ::Data 0.201306 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201306.tar.gz size: 583400 bytes md5: 98d834be02907395d61ad88039b9ba9a Changes from the previous release: * Olson database version 2013f (code 2013f, data 2013f): 427 canonical zones, 158 links * in prebuild, skip copying of the new NEWS file, which is not required -zefram
Re: DT:TZ 1.902
Dave Rolsky wrote: >So I tried installing the above tarball and it breaks a DateTime test >- t/34set-tz.t Bah. We had a test break of exactly that nature back at DateTime 0.72, in t/36invalid-local.t, based on the same change of error message. The resolution was to change the test in DT 0.73 to accept both forms of the error message. I think we should change t/34set-tz.t in the same way. > I think it'd be good to >keep this backwards compatible. Error messages get improved and sensitive tests get broken. It's part of the normal traffic of CPAN. (I'm smoking a few percent of CPAN at work, and distropreffing to keep it all working, so I get to see quite a bit of this sort of thing.) It's not to be done frivolously, but nor should over-sensitive tests hold back genuine improvements in error handling. DateTime failing its tests is a blocker for DT:TZ 2. I think it's the only blocker atm. -zefram
DT:TZ 1.902
Another new version of my DT:TZ rewrite. CPAN-style tarball at http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.902.tar.gz Public git repo at git://lake.fysh.org/zefram/DateTime-TimeZone.git The zic issues affecting a couple of zones have now been resolved. My zic patches were accepted upstream, and there's also a new version of the tzfile format which tackles tricky rules a different way. DT:TZ:Tzfile now handles the new tzfiles. Time::OlsonTZ::Data now has the hooks that the Debian folks want in order to roll their own version as part of their tzdata package. I think we're now (at last) on the point of being able to replace DT:TZ on CPAN. -zefram
Re: The State of the TimeZone in Debian
Time-OlsonTZ-Data-0.201305 has the prebuild features that you requested. You should be OK to incorporate it into the tzdata process now. -zefram
Time::OlsonTZ::Data 0.201305 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201305.tar.gz size: 583635 bytes md5: 4acdae056f145eef8e7e0eac9eae1844 Changes from the previous release: * Olson database version 2013e (code 2013e, data 2013e): 427 canonical zones, 158 links * support version-3 tzfiles as generated by the latest zic * in prebuild, skip copying of the new leap second related files, which are not required * in prebuild, support using a local copy of the Olson database in place of downloading * in prebuild, support building metadata files separately from tzfiles -zefram
Re: delta_data and time zones
Bill Moseley wrote: >What I'm wondering is if the dates are not floating should they be set to, >say, UTC, before comparing -- apples to apples, so to speak. That's a sane comparison to make, but, as you show, a different one from what delta_days does. Compatibility requires that we do not change the behaviour of delta_days. It's up to the user to decide which kind of comparison to do. -zefram
JSR-310
At YAPC::Europe 2013 I gave a talk about API design principles, illustrated using DateTime as an example of a popular module that causes pain by bad design. In places I contrasted it with the much better design of the new time library being standardised in the Java world, known as JSR-310 <http://download.java.net/jdk8/docs/api/java/time/package-summary.html>. One of the questions I got at the end of the talk was what we should use instead of DateTime, and I answered that we don't have well-designed modules covering all of its jobs, and I'd rather like to see someone implement JSR-310 for Perl. If anyone is motivated to port JSR-310, please mention it on this mailing list, to avoid duplication of effort and so on. Note that there's a public reference implementation, under the BSD licence. It'd probably also be worth communicating with Stephen Colebourne, the lead on the JSR-310 project, for insight into the design. -zefram
Re: The State of the TimeZone in Debian
intrigeri wrote: >Does it make sense? Did we miss anything? Any better idea? Your plan is essentially good. I'll put the hooks you want into the prebuild script. -zefram
Re: The State of the TimeZone in Debian
Sorry for the delay in dealing with this. I've turned out to not be as medically fixed up as I thought I was. Reviewing your libtime-olsontz-data-perl, I'm afraid your patch doesn't do enough. You've made the Perl module use the tzfiles from /usr/share/zoneinfo at runtime, so it gets whatever version of the files is currently installed as part of the tzdata package, but the rest of the module has baked-in metadata for a particular version of tzdata. You must do something to ensure that the module serves metadata for the same version of tzdata that is installed. The prebuild script, which you said you don't want to touch, is what generates the Perl source form of the metadata, based on the Olson database source. To do without prebuild entirely, you'd have to get the metadata into Perl form in some other way. Some of it (country-based zone selection data) is available under /usr/share/zoneinfo in a different form, but some (directional link data) is not. So it's not feasible to implement Time::OlsonTZ::Data correctly based entirely on data from the tzdata package as it currently exists. It would be a somewhat bad idea even if tzdata were minimally modified to make it possible: you'd be applying logic from Time::OlsonTZ::Download at runtime, somewhat inefficiently. A sensible approach really requires that you run the prebuild script against each version of the Olson database. You can use the wrapper part of Time-OlsonTZ-Data (from a CPAN version that you're happy with, eviscerated by "./prebuild bare") and apply it to each new Olson database version yourself, duplicating what I'd do to make a new version of Time-OlsonTZ-Data for CPAN. Your options really revolve around how you split data between the tzdata and libtime-olsontz-data-perl packages and how the packages are coupled. If you keep the metadata in the Time/OlsonTZ/Data.pm file, and keep the file in the libtime-olsontz-data-perl package, then libtime-olsontz-data-perl needs to declare that it depends on an exact version of tzdata. E.g., libtime-olsontz-data-perl 0.201304 depends on tzdata=2013d. Generally, any arrangement that has versioned data in both packages needs such a dependency declaration, in one direction or the other, to ensure that the packages upgrade in lockstep. Other options involve putting all the versioned data in the tzdata package. You'd keep the wrapper part of the Time-OlsonTZ-Data source around as build-helping code for the tzdata package. When building a new version of tzdata you'd apply the prebuild script to generate what amounts to the Time/OlsonTZ/Data.pm file, from its template, and then install that file as part of the tzdata package. In the simplest version, you generate the actual Time/OlsonTZ/Data.pm file, and install it directly into a Perl module directory. The libtime-olsontz-data-perl package could actually be superfluous that way. Another way, libtime-olsontz-data-perl installs a Time/OlsonTZ/Data.pm file that doesn't contain metadata itself but invokes the Perl file from the tzdata package to acquire it. -zefram
Re: How to correctly add a duration to not have it result in invalid date?
Bill Moseley wrote: >Again, developers of varying skills come and go and work on existing code. > So, they may not have any idea that "$start_time" has a timezone or think >about DST issues. Or that a day isn't always 24 hours. So teach them. If they're going to be working a lot in this problem domain, they ought to learn enough about it to avoid making basic errors. >What if DatTime Duration objects had a flag to say do the math in UTC? > Would that avoid the problem if it possibly failing? That would make the issue of what a DateTime::Duration actually represents even more confusing than it already is. >In my experience the floating times open up other headaches. We store all >times with a timezone -- we would rarely have something like "9am your >time" because of the ambiguity. I'm not suggesting that *you* forget which timezone applies. I'm suggesting that you do the date arithmetic without telling *DateTime* to apply a timezone. Do the date arithmetic in "floating" timezone, and store the resulting local time along with the timezone name. To compare the current time against this stored threshold, take the current time, express it in the stored timezone, then take the resulting current local time and compare that (sans timezone) against the stored local time. -zefram
Re: How to correctly add a duration to not have it result in invalid date?
Bill Moseley wrote: >If $dt and $duration can be anything, what's the best way to prevent adding >a $duration to a $dt and having it land on a non-existent date? Depends how broad your "anything" class is for durations. Calendar durations are not arithmetically well behaved, and there are several distinct ways in which calendar datetimes can fail to exist. >What would happen if duration calculations were always done in UTC? That would avoid DST-based failures. It does so by applying a different meaning of "day" from that which you're currently using. You need to decide what you actually mean by "day" when describing these expiry periods. You also need to decide whether you actually need a definite DateTime to represent the end of the period. Consider, especially when the period is years long, that DST rules are liable to before the period ends. Currently you're performing the addition in local time and (by virtue of putting the result into a DateTime with specified time zone) converting the result to UT based on the current best guess of what offset the zone will have at that time. Maybe you actually want a definite UT time for the end of the period. If that's the case, you probably want to interpret the duration in UT. Or maybe you need the end of the period to be defined in local time. In that case you'd be better just storing a notional local time without regard to current projection of whether DST will skip it. (You do that with DateTime by using the "floating" pseudo-timezone.) -zefram
Re: The State of the TimeZone in Debian
gregor herrmann wrote: >Before I file ITP bugs and upload them, I'd like to have some review; I'll look at them shortly. >What I'm also missing is the big picture how those package relate to >the good old DateTime::TimeZone with its tzfiles-converted-to-pm-files. >It's supposed to use Time::OlsonTZ::Data at some point, right? Right. There's a rewrite of DateTime::TimeZone, sitting in my repo, that does away with the pm-per-zone modules and uses Time::OlsonTZ::Data instead. We scheduled the official replacement of DateTime::TimeZone for 2012-09-01, but I was out of action for a few months due to a bout of depression, so I missed that. I'm picking up the pieces now, and we'll reschedule for some time in 2013. Whereas the current DateTime::TimeZone is volatile, due to including all the timezone data, the rewritten DateTime::TimeZone will not be volatile. The volatility is being localised in Time::OlsonTZ::Data (and, for you, the underlying tzdata package). >Do we need something else? I think we can skip >Time::OlsonTZ::Download, since we want to use our tzdata anyway, >right? And I think App::olson is also not required. T:OTZ:Download is a development tool. The build process for T:OTZ:Data uses it, even when working from local source, but your modified form of T:OTZ:Data build could manage without it if you tweak the prebuild script a bit. There's no need for ordinary users to have T:OTZ:Download. It would be nice to have App::olson packaged. (Preferably as "olson" rather than "libapp-olson-perl", because it's intended to be used as a command-line program rather than as a Perl module.) It is intended for ordinary users. But it's not necessary to package it at this stage: none of the timezone infrastructure depends on it. It is cleanly layered on top of Time::OlsonTZ::Data. -zefram
Time::OlsonTZ::Data 0.201210 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201210.tar.gz size: 592407 bytes md5: 138a1802d50d8315475b66f2c9811f0a Changes from the previous release: * Olson database version 2012j (code 2012j, data 2012j): 440 canonical zones, 142 links -zefram
Time::OlsonTZ::Data 0.201209 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201209.tar.gz size: 593422 bytes md5: 250e48cb102b840a6c711989260fed53 Changes from the previous release: * Olson database version 2012i (code 2012i, data 2012i): 440 canonical zones, 142 links -zefram
Time::OlsonTZ::Data 0.201208 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201208.tar.gz size: 592816 bytes md5: 094b652d130622d0e325fb015f96e256 Changes from the previous release: * Olson database version 2012h (code 2012h, data 2012h): 440 canonical zones, 142 links * in prebuild, handle new location for public domain notice in Olson tz-link.htm file -zefram
Time::OlsonTZ::Data 0.201207 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201207.tar.gz size: 587575 bytes md5: 659a8598a10f5a51b82d9b01427f4708 Changes from the previous release: * Olson database version 2012g (code 2012g, data 2012g): 440 canonical zones, 142 links -zefram
Re: best way to to make an easy to use "local" DateTime object?
Mark Stosberg wrote: >For a project that does a lot of object creation, I the shorthand could >still be nice. It's very little shortening, and only for that one operation (explicit construction of a DateTime). Use it in your app if you like, but I don't think it's a candidate for addition to the main DateTime distro. -zefram
Re: best way to to make an easy to use "local" DateTime object?
Mark Stosberg wrote: >It seems like a useful alternate design might be add this class method: > > DateTime->DefaultTimeZone($tz); That would make the "default timezone" a global variable. If two modules in one program both attempt to set it, you lose. If a module sets it and the main program also does, you lose. So to be safe, you can never set this in a reusable module. It gets worse. You're proposing to have this global variable used in places that currently use a constant. Effectively, lots of code that currently works fine by relying on the constant would now be reading the new variable. So if your main program sets the variable to any other value, and you're using any of the modules already on CPAN that rely on the current behaviour, you lose. >What do you think about the best way to set the time zone to "local" >across a large project? Which timezone a particular DateTime object needs is not so much a function of the application it's in, but of the way it's used in its immediate surroundings. There are three main cases, corresponding to the timezone designators "UTC" (for an absolute point in time), "floating" (for a calendar time in no particular zone), and "local" (for describing a point in time to users). A few applications need to use multiple local timezones, due to people crossing localities. Each piece of code that generates DateTime objects should know the broad purpose of those objects, and hence which kind of timezone they should use. They should generally set the timezone slot explicitly. Relying on the "floating" default is acceptable, but being explicit about it is better. -zefram
Time::OlsonTZ::Data 0.201206 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201206.tar.gz size: 587874 bytes md5: b6892ccf06bb28ff7b586d3bc9a2841e Changes from the previous release: * Olson database version 2012f (code 2012e, data 2012f): 440 canonical zones, 142 links -zefram
Time::OlsonTZ::Data 0.201205 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201205.tar.gz size: 583552 bytes md5: c77eabed1337d4fe576b13231180eb7d Changes from the previous release: * Olson database version 2012e (code 2012e, data 2012e): 440 canonical zones, 142 links -zefram
Re: working around nonexistent DateTimes (thanks to DST)
Thomas Klausner wrote: >I though a lot about how this could be done. The problem here of course >is that DateTime::TimeZone->new is called in various places in DateTime >(and potentially other code), so this new parameter would need to be handled >by DateTime AND DateTime::TimeZone: DT:TZ classes would have to support the functionality for it to work, but not for the reason you give. You're treating this behaviour as an inherent aspect of a timezone: > time_zone=>'America/Sao_Paulo:FIX',# ugly! ... > time_zone=>['America/Sao_Paulo' => 'fix_invalid_local_time' ], ... >Both of those ideas only have to be implemented in one place: >DateTime::TimeZone->new This is the wrong way round. The timezone you want is the same America/Sao_Paulo either way; you're just *doing something different with it*. The support you need for find-next-valid-local-datetime should be a new *method* in the DT:TZ API. DateTime->new, if asked (by flag parameter) to perform find-next-valid-local-time rather than to represent a time exactly, would apply logic that involves calling the new method on whatever timezone object was selected. The new method doesn't need to be available in all DT:TZ classes at once. (This is important because it won't be available in all: anyone can implement a compatible timezone object class to the current API.) When the new functionality is required, you only need the new method to exist on the timezone object that you're actually using. Availability can be detected with ->can, so you can get a clean error message when trying to use it with a timezone class that doesn't support it. -zefram
Re: Ah, leap seconds
Ben Tilly wrote: >Can we lose leap seconds now? That's being discussed over at . You should peruse the list archives, where all the points you raise have been discussed extensively. >From a DateTime point of view, the merits of leap seconds are irrelevant. Our job is to handle those that actually happen. -zefram
Re: working around nonexistent DateTimes (thanks to DST)
Thomas Klausner wrote: >The only potential deal-breaker is the fact that if you now create a new >DateTime that does not exists, you'll get the next valid time instead of >an exception Getting an exception in this situation is a feature, not a bug. Finding the next valid local time is potentially useful behaviour, but it needs to be invoked explicitly, perhaps by an extra constructor parameter. >Oh, and requesting a specific non-existed time also has strange results: >~$ perl -MDateTime -E 'say >DateTime->new(year=>2012,month=>10,day=>21,hour=>0,minute=>30,time_zone=>"America/Sao_Paulo")' >2012-10-21T01:30:00 If you're going to advertise this feature as "find the next valid local time", you need to handle cases like this correctly. -zefram
Re: Issue with finding next DST change, date math error?
Anthony Ball wrote: >So is that a bug in DateTime? No, it's just one of the ways in which date `arithmetic' isn't. > If I subtract one epoch time from another and >add shouldn't they end up together? The form of epoch seconds implemented by DateTime doesn't count leap seconds. So in the time scale supplied by DateTime it is *not* a linear count of elapsed seconds from a starting point. However, DateTime *does* supply some facilities that operate on linear seconds. You have presumably mixed the two kinds of operation. To get arithmetic to work as you expect, you can work entirely in epoch seconds. Do your arithmetic on the numerical values, never on DateTime objects. Use DateTime to convert the resulting values to objects, which you can then feed to DT:TZ objects. This is appropriate for your application. The alternative, to work in linear seconds (as perceived by DT), wouldn't be any better, because timezone objects at best just ignore the leap seconds that that would make visible to them. -zefram
Re: Issue with finding next DST change, date math error?
Anthony Ball wrote: >I never had any luck finding anything to give me the future DST changes for >a timezone We don't have an API for that. We've discussed it a bit, and will most likely add such a thing to the DT:TZ API after we've switched to the reimplemented DT:TZ, scheduled for 2012-09-01. > Now however the second >change in 2012 is coming up one second short, Smells like a leap second issue. There's a leap second scheduled for 2012-06-30T23:59:60Z. -zefram
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote:
>$ DateTime::Format::ISO8601->parse_datetime('2012W144T10:39+');
>2012-04-05T10:39:00
Oh, well spotted, that's entirely inconsistent. The input could correctly
be "2012-W14-4T10:39+00:00" or "2012W144T1039+".
-zefram
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote: >Do you have any reference from the official standard to this consistency >issue in the format? If so, I can take it up with Salesforce, since they >claim they're standards compliant and that's what's causing my pain. Referring to ISO 8601:2004. Clauses 2.3.3 and 2.3.4, defining "basic format" and "extended format", apply the concept to an entire date-and-time representation, rather than to segments of it, and doesn't mention any possibility of mixing the formats. Clasue 4.2.5.2, defining how to represent local time together with UT offset, separately shows basic and extended formats where separator usage matches, and doesn't give any explicit permission to mismatch them. Clause 4.3, on combining date with time of day, behaves similarly. -zefram
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Carl Vincent wrote: >I can't see a case where the lack of a colon in the time offset >introduces ambiguity in the parsing. It may be poor style, but it's not >necessarily broken. You've got to be careful about this sort of thing when there's an actual standard. Once you start accepting something that's not really conforming, generators start relying on it being accepted, and then get surprised when stricter parsers reject it, and the usefulness of the standard to everyone is thus reduced. The permissiveness that you ask for is not free of cost. Look at what happened historically to the dotted-octet representation of IPv4 addresses, described in some detail at <http://www.fysh.org/~zefram/text_rep/draft-main-ipaddr-text-rep.txt>. >Since these formats are out there in use, it would be better for the >module to parse them Best for *a* module to parse them. A module that doesn't claim that they're actually ISO 8601 formats, and by extension probably not the module with "ISO8601" in its name. "DateTime::Format::SalesForce" is available. -zefram
Re: ISO 8601 Format YYYY-MM-DDThh:mm:ss.sss[+-]hhmm
Thomas Klausner wrote:
>Though I'm not sure why (beeing not familiar with the spec), my patch
>was rejected.
ISO 8601 implies (but does not explicitly state) that you must be
consistent within a single expression about whether you use the
hyphen and colon separators ("extended format"). With the time of
day expressed as "10:39:00.000", the UT offset should be expressed as
"+00:00", not "+". So an ISO 8601 parser is justified in rejecting
"10:39:00.000+".
-zefram
Time::OlsonTZ::Data 0.201203 announcement
Shortly available from all good CPAN mirrors: file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201203.tar.gz size: 583082 bytes md5: 83fba384d3de2f3b763ed4870223e1dd Changes from the previous release: * Olson database version 2012c (code 2012b, data 2012c): 440 canonical zones, 142 links * include Olson database source, and prebuild code to generate data files, in distribution * load File::Spec and Carp lazily * build metadata structures lazily, with country selection data in a separate file * add App::olson to "see also" list -zefram
Re: packaging Time::OlsonTZ::Data
Dave Rolsky wrote: >It's not like maintaining DT::TZ and updating it when there are new >Olson releases is a big hassle, so I don't mind doing it for a while. Yes, that's another issue I was planning to raise. Continued DT:TZ 1.xx releases would give distros the choice of a lengthy period in which to switch. There are enough 1.xx version numbers left for another couple of years. >I'll suggest September 1 as the cutover date when Zefram will release >DateTime::TimeZone 2.00 using the new code base. Works for me. There's one remaining unresolved item, the zic bugs, but if that's not resolved on the Olson end by September then I'll put some workaround into DT:TZ:Tzfile. -zefram
packaging Time::OlsonTZ::Data
Hi, I'd like to establish what's going to happen about packaging my CPAN module Time::OlsonTZ::Data for OS distros. I'm writing to (as far as I can tell) the current Debian and Fedora maintainers of DateTime::TimeZone packages, and I'm CCing the relevant perl.org mailing list. We're now getting close to replacing the current DateTime::TimeZone with a rewrite that will use Time::OlsonTZ::Data as its source of Olson-derived timezone data. Iain Arnell raised an issue about T:OTZ:D not coming in a true source form. I've got a new version of the wrapper system that I think resolves this. <http://www.fysh.org/~zefram/tmp/Time-OlsonTZ-Data-0.20120201.tar.gz> is a test version of the module distribution, which bundles (the important parts of) the Olson database source, and the automation to build the tzfiles, as well as bundling the prebuilt tzfiles. I can't not bundle the tzfiles, because this has to support Perl users in places where the Olson build code can't be used (because it's Unix-specific and requires a C compiler), but you can now throw away the tzfiles and build from proper source. This version of the module should be a better base from which to customise the module, where you need to. Please let me know what you think of this arrangement. I'll be releasing a new version of T:OTZ:D every time there's a new Olson database release, as I have done for the past year and a half. (The current version of DateTime::TimeZone is also on this release schedule, but the rewrite won't be, having delegated the volatility to T:OTZ:D.) Sometimes Olson database updates are urgent, requiring promulgation on a timescale of days, and T:OTZ:D updates will inherit that urgency. In Debian, T:OTZ:D ought to be handled through the volatile-data mechanism. Is that OK? In Fedora, I don't know what you do for such things. Please discuss. Somewhat interacting with the above, you have the option to apply the T:OTZ:D automation to a new version of the Olson database independently of my releases. Iain Arnell suggested extending the existing tzdata package to build a matching Time/OlsonTZ/Data.pm this way, not needing a separate package for the module. You'd also have it point at your existing tzfiles in /usr/share/zoneinfo, rather than having a separate copy. That's quite feasible with the new form of the module distribution. -zefram
Re: Adding datetime to Foswiki
Julian Levens wrote: >The wiki stores it's data in text files but has never supported a datetime >field. We are now looking at adding such a field and we really want to get >this right first time. What you should put in the field depends on what you want to use it for. No single arrangement is right for every purpose. If your answer would be "general purpose", then you need more than one type. >We see three fundamental parts to a datetime field. You'll tend to want some combination of these parts, but probably not all three at once. If you want to record the time at which some event historically occurred, just represent it in UT, with no timezone offset or name. If you're scheduling an event for the future, and can't constrain it all to UT, then you probably want date, time of day, and timezone name: the offset that will be used by that timezone at the relevant time won't be truly known until it arrives, so the offset isn't an adequate substitute for the name. Recording an offset is for when you're timestamping an historical action, and you want to know both when it occurred and what the local time was for the actor. >Is there anything else we need to consider? You should consider what resolution you're really after. If you want your timestamps to be sub-second meaningful then you need to be clear about which flavour of UT you're using (probably UTC, in which case you need to handle leap seconds properly). -zefram
DT:TZ 1.901
New version of my DT:TZ rewrite. CPAN-style tarball at http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.901.tar.gz Public git repo at git://lake.fysh.org/zefram/DateTime-TimeZone.git I believe this version resolves all the issues that people raised with 1.900. Comments welcome, of course. There remain a couple of problems with current tzfiles that show up when they're used through DT:TZ:Tzfile: $ olson list 'o@now!?' o@now k ???Africa/Cairo ???America/Argentina/San_Luis Patches for zic are pending with the Olson folks. This blocks switching to the rewrite, because it would be a regression, because current DT:TZ (because it doesn't use tzfiles) doesn't suffer these zic bugs. Also need to sort out how Time::OlsonTZ::Data is going to be handled by Debian et al. I think I'll need to distribute it in two forms, one with precompiled tzfiles (for platform portability) and one bundling tzcode/tzdata (for source editability). -zefram
