Re: [BUG] Empty spans/spansets have infinite duration?
On Thu, Apr 02, 2009 at 08:29:38PM +0200, Flavio S. Glock wrote: > Fixed in DateTime::Set 0.27 > > 0.27 2009-04-02 > - fixed DateTime::Spanset duration() method. > Reported by Anton Berezin Thanks a bunch. It took me a while to revert a workaround in production code and to verify the fix, but it works perfectly now. \Anton. -- There is no beauty in entropy. -- Eliezer Yudkowsky
[BUG] Empty spans/spansets have infinite duration?
Hi, It's a bit tricky to say which particular module needs to be changed to fix this bug, hence I am not using RT for reporting it. The good part is that all candidate modules appear to have the same author. :-) The test case is as follows: #! /usr/bin/perl use strict; use warnings; use DateTime; use DateTime::Duration; use DateTime::Span; use Data::Dumper; my $bad_s = DateTime->new(year => 2009, month => 1, day => 12, hour => 1, minute => 0, second => 0); my $bad_e = DateTime->new(year => 2009, month => 1, day => 12, hour => 6, minute => 0, second => 0); my $bad = DateTime::Span->from_datetimes(start => $bad_s, end => $bad_e); my $good = $bad->complement; my $interest_s = DateTime->new(year => 2009, month => 1, day => 12, hour => 4, minute => 30, second => 0); my $interest_e = DateTime->new(year => 2009, month => 1, day => 12, hour => 5, minute => 0, second => 0); my $interest = DateTime::Span->from_datetimes(start => $interest_s, end => $interest_e); my $r = $interest->intersection($good); my $d = $r->duration; print Dumper $d; my $d0 = DateTime::Duration->new(seconds => 0); print Dumper $d0; I would certainly expect for the duration $d of the empty set $r to be the same duration as $d0, that is, zero seconds. Instead it behaves more like infinity. Is that something that you might be interesting in fixing? Thanks, \Anton. -- There is no beauty in entropy. -- Eliezer Yudkowsky
Re: DateTime::TimeZone problems on FreeBSD
On Thu, Dec 04, 2003 at 02:12:27PM -0600, Dave Rolsky wrote: > On Thu, 4 Dec 2003, Anton Berezin wrote: > > > > Setting your system's time zone to such a thing is asking for trouble. > > > > I really don't know. Three-letter abbreviations are POSIX.1. They > > might be obsolete, but they are still supported by most implementations, > > and used widely. > > POSIX is wrong. What else can I say? POSIX also said that 2000 wasn't a > leap year, IIRC. > > > "Tools not policy" seem to apply here. > > I'm not sure what that means. > > This isn't a policy issue, it's a question of being correct. "EST" is not > a valid Olson database time zone. If you want to make up some bogus ad > hoc rule then you can always declare that "EST = America/New_York", but if > you have to deal with users who may be in multiple time zones for a single > app, especially something like a web app where you have one database > (probably storing UTC) and a need to output datetimes in multiple zones, > then you'll have to do this correctly. > > As for the DateTime project, there's a DateTime::TimeZone::Alias module > that lets you associate arbitrary names (abbreviations or whatever) with a > real time zone name. > > But you'd have to define the EST => America/New_York mapping in your own > code. Stuff like that will never be part of the core. Maybe have a default aliases like "certain annoying OS's", to borrow your expression? As a matter of fact, last time I tried, Linux did the same thing - understood them. "EST" actually designates Indianapolis time - America/Indianapolis and EST are hardlinked (I presume because it is "EST" all year round), and "CET" is, I believe, quite unambiguous. Even funnier still, the zoneinfo package is exactly the same on Linux and FreeBSD, or at least on Debian and FreeBSD, and there is a whole bunch of three-letter abbreviations there. So why to struggle against the OS? For an abstract correctness, which might not be that correct after all (what if I live in Andorra and ask for CET times before 1985; they are different from Andorra times) ? Since you did not buy the "tools not policy" principle, I appeal to the "principle of least astonishment", which in this particular instance means to support what people expect and what OS's implement. You may "strongly urge against using three letter abbreviations" because they are not correct, but not supporting them outright would, IMHO, be a mistake. Cheers, \Anton. -- Civilization is a fractal patchwork of old and new and dangerously new. -- Vernor Vinge
Re: DateTime::TimeZone problems on FreeBSD
On Thu, Dec 04, 2003 at 12:42:18PM -0600, Dave Rolsky wrote: > On Thu, 4 Dec 2003, Mathieu Arnold wrote: > > > +-le 04/12/2003 10:05 -0600, Dave Rolsky écrivait : > > | On Thu, 4 Dec 2003, Anton Berezin wrote: > > | > > |> - even if TZ is set, it is very likely to contain something like "CET", > > | > > | That's not a time zone. > > > > Hum, what is it if not a time zone ? > > It's a 3 letter abbreviation that _could_ represent one _or more_ time > zones, at least sometimes. > > In other words, these abbreviations are not unique, nor are they > indicative of exactly what rules are in effect. > > For example, EST is used for "Eastern Standard Time", aka > America/New_York, but also for parts of Australia. > > Even EST in the US is ambiguous, because it's also used for > America/Indianapolis, a time zone that does not observe DST, in addition > to America/New_York, which does observe EST. > > There's been discussion about this on the list, but I'll repeat this over > and over. The various 3 and 4 letter abbreviations sometimes used > colloquially for time zones are often not sufficient to accurately > determine what the actual time zone is, and should only be used for > display purposes, as in "January 4, 2003 11:00 EST". > > Setting your system's time zone to such a thing is asking for trouble. I really don't know. Three-letter abbreviations are POSIX.1. They might be obsolete, but they are still supported by most implementations, and used widely. "Tools not policy" seem to apply here. Cheers, \Anton. -- Civilization is a fractal patchwork of old and new and dangerously new. -- Vernor Vinge
DateTime::TimeZone problems on FreeBSD
Hi, [Please Cc me in any replies, since I am not on the list] With DateTime::TimeZone 0.25.05, the following is likely to bork with "Cannot determine local time zone": perl -MDateTime::TimeZone -le '$t = DateTime::TimeZone->new(name => "local");' The reasons for that are: - if TZ environment variable is not set, TimeZone tries /etc/localtime, which is present on FreeBSD. Unfortunately, on FreeBSD this file is *NOT* a symlink to a timezone name, but a FreeBSD-specific binary file (see tzfile(5) for details); - even if TZ is set, it is very likely to contain something like "CET", which DateTime::TimeZone knows nothing about. Only if TZ is set to something like "Europe/Copenhagen", will DateTime::TimeZone work, and this is in my experience very uncommon among FreeBSD users. - the other methods DateTime::TimeZone tries are not applicable for FreeBSD. I have too little knowledge of the module inner workings to provide a patch, unfortunately. Cheers, %Anton. -- Civilization is a fractal patchwork of old and new and dangerously new. -- Vernor Vinge
