Re: hires DateTime-from_epoch( epoch = ... ) values
Since nobody has commented on this patch does that mean everybody agrees
that it's a good idea? :)
-J
--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test values used in Date::Parse is 1045469647.198189,
which is just beyond the precision of an IEEE 754 64bit value (a C
double). So internally (on all IEEE 754 compliant platforms, YMMV) this
gets represent as 1045469647.198189020... . Since
DateTime-from_epoch() treats the epoch parameter as numeric, it
currently creates an object from that number set to 198_189_020
nanoseconds. I believe that this is surprising behavior for most users;
in general people don't think about using an epsilon when comparing
integer values.
Possible solutions:
a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the epoch parameter into a Math::BigFloat so a high resolution
'string' can be passed in and document the behavior.
It's not clear to me what the right solution is although a patch to
implement option d sans the required documentation changes is attached.
Cheers,
-J
--
? .swp
? DateTime-0.2901-from_epoch_precision-fix.patch
? DateTime.bs
? DateTime.c
? Makefile
? blib
? leap_seconds.h
? pm_to_blib
? tmp.pl
? t/zz_00load.t
? t/zz_01sanity.t
? t/zz_02last_day.t
? t/zz_03components.t
? t/zz_04epoch.t
? t/zz_05set.t
? t/zz_06add.t
? t/zz_07compare.t
? t/zz_09greg.t
? t/zz_10subtract.t
? t/zz_11duration.t
? t/zz_12week.t
? t/zz_13strftime.t
? t/zz_14locale.t
? t/zz_15jd.t
? t/zz_16truncate.t
? t/zz_17set_return.t
? t/zz_18today.t
? t/zz_19leap_second.t
? t/zz_20infinite.t
? t/zz_21bad_params.t
? t/zz_22from_doy.t
? t/zz_23storable.t
? t/zz_24from_object.t
? t/zz_25add_subtract.t
? t/zz_27delta.t
? t/zz_28dow.t
? t/zz_29overload.t
? t/zz_30future_tz.t
? t/zz_31formatter.t
? t/zz_32leap_second2.t
? t/zz_33seconds_offset.t
? t/zz_34set_tz.t
? t/zz_35rd_values.t
? t/zz_36invalid_local.t
Index: Makefile.PL
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
retrieving revision 1.47
diff -u -r1.47 Makefile.PL
--- Makefile.PL 27 Feb 2005 03:27:25 - 1.47
+++ Makefile.PL 26 Jul 2005 01:41:35 -
@@ -83,6 +83,7 @@
PREREQ_PM= { 'DateTime::Locale' = 0.21,
'DateTime::TimeZone' = 0.26,
+ 'Math::BigFloat' = 0,
'Params::Validate' = 0.76,
'Pod::Man'= 1.14,
'Test::More' = 0.34,
Index: lib/DateTime.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.304
diff -u -r1.304 DateTime.pm
--- lib/DateTime.pm 7 Jul 2005 23:18:21 - 1.304
+++ lib/DateTime.pm 26 Jul 2005 01:41:38 -
@@ -48,6 +48,7 @@
use DateTime::TimeZone;
use Params::Validate qw( validate validate_pos SCALAR BOOLEAN HASHREF OBJECT
);
use Time::Local ();
+use Math::BigFloat;
# for some reason, overloading doesn't work unless fallback is listed
# early.
@@ -435,8 +436,8 @@
my %args;
# Because epoch may come from Time::HiRes
-my $fraction = $p{epoch} - int( $p{epoch} );
-$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
+my $fraction = Math::BigFloat-new( $p{epoch} ) - int( $p{epoch} );
+$args{nanosecond} = int ( $fraction * MAX_NANOSECONDS )-as_int-bstr
if $fraction;
# Note, for very large negative values this may give a blatantly
Index: t/04epoch.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
retrieving revision 1.18
diff -u -r1.18 04epoch.t
--- t/04epoch.t 13 Nov 2004 21:22:36 - 1.18
+++ t/04epoch.t 26 Jul 2005 01:41:38 -
@@ -2,7 +2,7 @@
use strict;
-use Test::More tests = 32;
+use Test::More tests = 34;
use DateTime;
@@ -126,3 +126,13 @@
my $dt = DateTime-from_epoch( epoch = 0.1234567891 );
is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
}
+
+{
+my $dt = DateTime-from_epoch( epoch = 123456789.1234567891 );
+is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
+}
+
+{
+my $dt = DateTime-from_epoch( epoch = 1045469647.198189 );
+is( $dt-nanosecond, 198_189_000, 'nanosecond should be an integer ' );
+}
pgphQzDt5zeaD.pgp
Description: PGP signature
[announce] DateTime::Format::ISO8601 0.0403
The 'Al might be a whiner' release. Released to CPAN. Changes since 0.0402 - update doc format - tidy Build.PL - auto-generate Makefile.PL - change set_base_datetime() to use DT's overloaded = instead of -compare() - tidy test sources and reduce runtime Cheers, -J -- pgp62mojsubeJ.pgp Description: PGP signature
Store DateTime::Event::Cron objects ?
Hi I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible?
Re: Store DateTime::Event::Cron objects ?
I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible? The same question goes for DateTime::Set objects. Can they be made persistent?
Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution 'string' can be passed in and document the behavior. It's not clear to me what the right solution is although a patch to implement option d sans the required documentation changes is attached. That seems right to me. Does anyone object to adding Math::BigFloat as a prereq? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Store DateTime::Event::Cron objects ?
Hello Kaare, I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible? Since, in essence, DT::E::Cron is designed to convert cron strings into datetime recurrences, why not use the original cron specification as the string to be stored? The original() method will return the string used to construct the object. Matt
Re: hires DateTime-from_epoch( epoch = ... ) values
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues. (I only really care about per-object overhead, not the cost of loading Math::BigFloat itself.) -John
Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, 8 Aug 2005, John Siracusa wrote: On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues. (I only really care about per-object overhead, not the cost of loading Math::BigFloat itself.) If I read the patch directly, we never store the bigfloat object, we just use it to make sure that nanoseconds has the right value. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
RE: hires DateTime-from_epoch( epoch = ... ) values
On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution 'string' can be passed in and document the behavior. It's not clear to me what the right solution is although a patch to implement option d sans the required documentation changes is attached. That seems right to me. Does anyone object to adding Math::BigFloat as a prereq? No objections here :-) I just installed on WNT without issues (Clean install on this OS) Ron
Re: Store DateTime::Event::Cron objects ?
Since, in essence, DT::E::Cron is designed to convert cron strings into datetime recurrences, why not use the original cron specification as the The not-so-easy part is my small addition: The same question goes for DateTime::Set objects. Can they be made persistent?
Re: Store DateTime::Event::Cron objects ?
Quoting Kaare Rasmussen [EMAIL PROTECTED]: The same question goes for DateTime::Set objects. Can they be made persistent? Flavio was working on something along these lines, though I'm not sure of the current status. Check out the following thread: http://marc.theaimsgroup.com/?l=perl-datetimem=111524990432703w=2 Matt
Re: Store DateTime::Event::Cron objects ?
2005/8/8, Matt Sisk [EMAIL PROTECTED]: Quoting Kaare Rasmussen [EMAIL PROTECTED]: The same question goes for DateTime::Set objects. Can they be made persistent? Flavio was working on something along these lines It actually worked, but the performance was too bad for complex sets. The database was not able to optimize the queries, and the execution time grew exponentially. I think the solution for storing in a database still is to iterate the set and store the dates. The best alternative would be to use a calendar server. About making the recurrences persistent - DateTime::Event::ICal can stringify and instantiate back most recurrences generated with DateTime::Event::Recurrence and DateTime::Event::ICal. - Flavio S. Glock
Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, Aug 08, 2005 at 09:31:10AM -0500, Dave Rolsky wrote: On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution 'string' can be passed in and document the behavior. It's not clear to me what the right solution is although a patch to implement option d sans the required documentation changes is attached. That seems right to me. Does anyone object to adding Math::BigFloat as a prereq? You may want to require a recent version; Tels has done a great job maintaining the Math::Big* modules, but AIUI they started off (and were shipped in older perls) with quite a few bugs.
