Re: Rethinking date math, time zones, etc for Perl 6 (and maybe DateTime2?)
John Peacock wrote: and at any point in that sequence, allow the user to set the value to undef (for "I don't have any information about anything below this"). All math operations would then stop at the point where either term (for binary operations) contained an undef (hence two disimilarly accurate DT objects would have a result no more accurate than the least accurate term). This would allow reduced precision date math to happen naturally. DateTime::Incomplete http://search.cpan.org/dist/DateTime-Incomplete/lib/DateTime/Incomplete.pm It doesn't handle the "add" methods, but it could do it. I don't know if it would handle DST correctly. How about writing a test? - Flavio S. Glock
Re: Rethinking date math, time zones, etc for Perl 6 (and maybe DateTime2?)
On 6/15/05, Dave Rolsky <[EMAIL PROTECTED]> wrote: > Also, I think we may need to consider serious backwards incompatibility in > the future of DateTime.pm (possibly via a new namespace like DateTime2) to > really clean this up, but that'll wait til I'm less tired ;) Just break it. DateTime's nowhere near version 1.0. Anyone who was relying on its API stability was not doing so based on any "official" advice, AFAIK. -John
Re: Rethinking date math, time zones, etc for Perl 6 (and maybe DateTime2?)
Dave Rolsky wrote: - Work with just dates and do date math on them (at the level of days, months & years). I think I was one of the ones advocating for a way to do this, since in a business environment, the time is frequently not important (for example number of days between order and shipment, or shipment and payment). I'd have to look back at the archives, but I believe I suggested either undef for the time values or internally setting the time to a fixed UTC time for all DT objects without time (like 12 noon, to stay away from any possible leap-day magic). It would require all math operations to be smarter, but I don't think it would require a completely redesigned API. For example, consider an object like this: year, month, day, hour, minute, second, TZ and at any point in that sequence, allow the user to set the value to undef (for "I don't have any information about anything below this"). All math operations would then stop at the point where either term (for binary operations) contained an undef (hence two disimilarly accurate DT objects would have a result no more accurate than the least accurate term). This would allow reduced precision date math to happen naturally. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Kind of mess....be cool...
Hi again, I'm trying to understand some things related to TZ database. One big question: in the modules of the cities, what does it mean [ DateTime::TimeZone::NEG_INFINITY, 59421774992, DateTime::TimeZone::NEG_INFINITY, 59421772800, -2192, 0, 'LMT' ] or [ 60446127600, 60457881600, 60446131200, 60457885200, 3600, 1, 'WEST' ] ? The numbers, I can figure that are the number of seconds elapsed from a date ( if it is 1/1/1 A.D. 0h00m00s it might be wrong its calculation - but only seeing better ). Ok: which date? Second: what does it means? - it's sequence, etc. Please - someone - answer to this questions. I might be able to help figuring out this mess... Kind regards Rui Miguel Fernandes Porto - Portugal
Rethinking date math, time zones, etc for Perl 6 (and maybe DateTime2?)
So there's been a bunch of date math + TZ related bugs lately in DateTime.pm, and more to be resolved. I think the fundamental problem is that DateTime.pm is trying to cover a few too many bases in one "simple" API. There are a bunch of things people would like to be able to do: - Work with just dates and do date math on them (at the level of days, months & years). The current implementation is quite broken for this purpose, because when you assign a non-UTC time zone to your object and do date math, the math is done on the underlying UTC time, which causes weird results. - Work with local datetimes and do datetime math on them, by manipulating the _local_ time, so that adding one hour is adding one hour to the wall clock time. - Work with local datetimes and do datetime math on them, but using the underlying UTC time. This shouldn't make a difference when adding or subtracting a duration, but it does make a differnce when determining the interval between two datetimes. Then there are some duration-related issues. People want to: - Have a duration that's anchored on a given datetime, in other words a duration as a start & end point versus ... - Have a duration that is simply a period of time (5 hours), and is unchanged based on the points in time. The former could incorporate both positive and negative components (+10 days, -5 hours), while the latter never should. The current DT::Duration object mixes these concepts together. You _can_ create one with positive & negative components, but DateTime.pm will never give you such a thing. I see that Sam Tregar already started on some date-related classes for Pugs, but I don't think he's thought through a lot of this stuff, at least based on the API he's proposing. Anyway, I thought I'd throw this stuff out there since it might be useful to summarize for Perl6, no matter who ends up working on its Datetime stuff. Also, I think we may need to consider serious backwards incompatibility in the future of DateTime.pm (possibly via a new namespace like DateTime2) to really clean this up, but that'll wait til I'm less tired ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Mixed Info, perhaps?
Hi, I made some calculations ( conversions between GMT and Europe/Lisbon ) in the websites referred at http://www.twinsun.com/tz/tz-link.htm, like "The World Clock" or "Time Zone Converter . I looked for some difficult examples. But here they are: In the 25th September 1977, in Europe/Lisbon, the difference to GMT changed to 0h at 1 A.M. If I calculate the time offset in the above websites, I get that this null difference is assumed not at 1 A.M., but from 0h A.M. forward. In the 30th September of 1979, in the same location, the difference ( before of one hour ) is 0h, regarding GMT, at 2 A.M. According to their program, again, this change begins either at 1 A.M. or 0h AM, of that day - not at 2 A.M., at it was suposed to be. Is this an error in their calculations? Or is the TZ Database wrong? Kind regards, Rui Miguel Fernandes Porto - Portugal
Re: DT::Duration behaviour .. LSB or MSB?
On Wed, 15 Jun 2005, Rick Measham wrote:
renard wrote:
I quote from perldoc DateTime:
"DateTime.pm" always adds (or subtracts) days, then months, minutes, and
then seconds. If there are any boundary overflows, these are normalized
at each step.
Dave, if you're following this, can you tell me if there's a reason why you
do this mixed up order?
I think it was just easiest ;)
P.S. Dave, Here's quick hacks of the two functions I'd like to see added ...
there's no checking that we really have a duration or anything like that...
sub add_lsb {
my ($self, $duration) = @_;
foreach (qw/nanosecond second minute hour day month year/) {
$self->add( $_ => $duration->$_ ) if $duration->$_
}
return $self;
}
sub add_msb {
my ($self, $duration) = @_;
foreach (reverse qw/nanosecond second minute hour day month year/) {
$self->add( $_ => $duration->$_ ) if $duration->$_
}
return $self;
}
I really don't want to clutter up the DateTime API any more than it
already is. I think we need some sort of mixin or wrapper namespace like
we've talked about before.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
[PATCH] Make Time::Local to load Carp only when nec.
-BEGIN PGP SIGNED MESSAGE-
Moin,
please see attached patch.
All tests successful.
u=2.75 s=0.68 cu=184.66 cs=24.10 scripts=949 tests=107137
real6m7.867s
user3m10.656s
sys 0m26.229s
Best wishes,
Tels
- --
Signed on Wed Jun 15 12:16:26 2005 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
" ...the Machholz Comet is named after the guy who really discovered it.
Bob Comet." -- Zathras26 (763537) on 2005-01-01 at /.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQrACFHcLPEOTuEwVAQF03gf/UQwINZMhupDhk0QSh7/YrxoCetfgGGfh
sfjnGfnIK5X9PTdiqoP/JC8+lkrjIYj6EcUdDrwY5ChSWG8zXMpv34tcmeHP7NwM
z7x2q0tNSMUE1qwMa9xbOAAiivFd/wHw/hkQzvMCwQijpeDPREzRcP2H6CEIzYQr
9LmntPNJGy1D74hOKvPTeSC51ak/gisH1hFeJDo+3Y4YqrO2WSjyarBsGWcmkvU2
9ztJgCeprlzyc7USEJ6Dpv9Ht+4ltZHWSurSsUHjrp/9+Rzqho173hKnsEI/xrwH
WgMlFm+Y4Z6id0jnvr9SFOF+ZHayLsPiKbKPdJfAX7jlK7bL1XbP5A==
=bVGF
-END PGP SIGNATURE-
diff -ruN blead/lib/Time/Local.pm blead.patch/lib/Time/Local.pm
--- blead/lib/Time/Local.pm 2005-02-10 12:25:50.0 +0100
+++ blead.patch/lib/Time/Local.pm 2005-06-15 12:10:35.0 +0200
@@ -1,13 +1,12 @@
package Time::Local;
require Exporter;
-use Carp;
use Config;
use strict;
use integer;
use vars qw( $VERSION @ISA @EXPORT @EXPORT_OK );
-$VERSION= '1.11';
+$VERSION= '1.12';
$VERSION= eval $VERSION;
@ISA = qw( Exporter );
@EXPORT= qw( timegm timelocal );
@@ -96,6 +95,12 @@
($day, $sec);
}
+sub _croak
+ {
+ # load Carp on demand, as to not waste memory in non-error cases
+ require Carp;
+ goto &Carp::croak;
+ }
sub timegm {
my ($sec,$min,$hour,$mday,$month,$year) = @_;
@@ -110,20 +115,18 @@
unless ($Options{no_range_check}) {
if (abs($year) >= 0x7fff) {
$year += 1900;
- croak "Cannot handle date ($sec, $min, $hour, $mday, $month,
*$year*)";
+ _croak ("Cannot handle date ($sec, $min, $hour, $mday, $month,
*$year*)");
}
- croak "Month '$month' out of range 0..11" if $month > 11 or $month < 0;
+ _croak ("Month '$month' out of range 0..11") if $month > 11 or $month <
0;
my $md = $MonthDays[$month];
-#++$md if $month == 1 and $year % 4 == 0 and
-#($year % 100 != 0 or ($year + 1900) % 400 == 0);
++$md unless $month != 1 or $year % 4 or !($year % 400);
- croak "Day '$mday' out of range 1..$md" if $mday > $md or $mday <
1;
- croak "Hour '$hour' out of range 0..23" if $hour > 23 or $hour <
0;
- croak "Minute '$min' out of range 0..59" if $min > 59 or $min <
0;
- croak "Second '$sec' out of range 0..59" if $sec > 59 or $sec <
0;
+ _croak ("Day '$mday' out of range 1..$md") if $mday > $md or
$mday < 1;
+ _croak ("Hour '$hour' out of range 0..23") if $hour > 23 or
$hour < 0;
+ _croak ("Minute '$min' out of range 0..59") if $min > 59 or
$min < 0;
+ _croak ("Second '$sec' out of range 0..59") if $sec > 59 or
$sec < 0;
}
my $days = _daygm(undef, undef, undef, $mday, $month, $year);
@@ -138,7 +141,7 @@
warn "Sec too small - $days < $Min{Sec}\n" if $days < $Min{Sec};
warn "Sec too big - $days > $Max{Sec}\n" if $days > $Max{Sec};
$year += 1900;
- croak "Cannot handle date ($sec, $min, $hour, $mday, $month, $year)";
+ _croak ("Cannot handle date ($sec, $min, $hour, $mday, $month, $year)");
}
no integer;
Houston, I have a problem
Good morning, I'm trying to implement DateTime::TimeZone in one of my applications. But I keep getting errors: missing modules, etc. The last error is: Can't locate loadable object for module DateTime in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Perl/lib/XSLoader.pm line 42 BEGIN failed--compilation aborted at DateTime/DateTime.pm line 42. How do I solve this one? Regards, Rui Fernandes
More ravings .. this time something really *is* wrong!
OK, you can mainly ignore my previous posts .. I'm still interested in
them, but there's a large hole that needs plugging first:
Once I set my local time zone I get incorrect results!
It looks like the time zone is adding a leap day between Nov 17 and Jan
1st in Melbourne! Oops!
#This one works:
$d1=DateTime->new(year=>2004);
$d2=$d1->clone->add(days=>-45);
$d=$d2-$d1;
print Dumper($d, {($d2-$d1)->deltas})
2004-01-01T00:00:00
2003-11-17T00:00:00
$VAR1 = {
'seconds' => 0,
'minutes' => 0,
'nanoseconds' => 0,
'days' => -14,
'months' => -1
};
#This one doesn't
$d1=DateTime->new(year=>2004,time_zone=>"Australia/Melbourne");
$d2=$d1->clone->add(days=>-45);
$d=$d2-$d1;
print Dumper($d, {($d2-$d1)->deltas})
2004-01-01T00:00:00
2003-11-17T00:00:00
$VAR1 = {
'seconds' => 0,
'minutes' => 0,
'nanoseconds' => 0,
'days' => -15,
'months' => -1
};
#This one *does*
$d1=DateTime->new(year=>2004,time_zone=>"America/New_York");
$d2=$d1->clone->add(days=>-45);
$d=$d2-$d1;
print Dumper($d, {($d2-$d1)->deltas})
2004-01-01T00:00:00
2003-11-17T00:00:00
$VAR1 = {
'seconds' => 0,
'minutes' => 0,
'nanoseconds' => 0,
'days' => -14,
'months' => -1
};
