Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime CPAN distribution.

Report information
The Basics
Id: 92594
Status: resolved
Priority: 0/
Queue: DateTime

People
Owner: Nobody in particular
Requestors: stuart.kendrick.sea [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: epoch_hires is not reporting nanoseconds
Date: Thu, 30 Jan 2014 15:26:27 -0800
To: bug-DateTime [...] rt.cpan.org
From: Stuart Kendrick <stuart.kendrick.sea [...] gmail.com>
I would predict that the following script would output 1391124605.000000004 instead, it outputs 1391124605 TEST SCRIPT ===================================== $ cat ./test.plx #!/usr/bin/perl use strict; use warnings; use feature 'say'; use DateTime; my ($dt, $epoch); $dt = DateTime->new( year => 2014, month => 1, day => 30, hour => 15, minute => 30, second => 5, nanosecond => 4, time_zone => 'local', ); say $dt; $epoch = $dt->hires_epoch; say $epoch; ======================================== SAMPLE OUTPUT $ ./test 2014-01-30T15:30:05 1391124605 $ ==> I would have expected 1391124605.000000004 VERSIONS DateTime-1.0.6 perl -v This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi (with 56 registered patches, see perl -V for more detail) uname -a Linux gnat 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Here is a partial Data::Dumper dump of $dt $VAR1 = bless( { 'local_rd_secs' => 55805, 'local_rd_days' => 735263, 'utc_c' => { 'epoch' => 1391124605 }, 'rd_nanosecs' => 4, 'locale' => bless( { 'default_time_format_length' => 'medium', 'native_territory' => 'United States', 'native_language' => 'English', 'native_complete_name' => 'English United States', 'en_language' => 'English', 'id' => 'en_US', 'default_date_format_length' => 'medium', 'en_complete_name' => 'English United States', 'en_territory' => 'United States' }, 'DateTime::Locale::en_US' ), 'local_c' => { 'hour' => 15, 'second' => 5, 'month' => 1, 'quarter' => 1, 'day_of_year' => 30, 'day_of_quarter' => 30, 'minute' => 30, 'day' => 30, 'day_of_week' => 4, 'year' => 2014 }, 'utc_rd_secs' => 84605, 'formatter' => undef, 'tz' => bless( { 'last_offset' => -28800, 'spans' => [ [ '-inf', '60502413600', '-inf', '60502384800', -28800, 0, 'PST' ], [ [...] --sk
Subject: Re: [rt.cpan.org #92594] epoch_hires is not reporting nanoseconds
Date: Thu, 30 Jan 2014 17:41:56 -0600 (CST)
To: Stuart Kendrick via RT <bug-DateTime [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Thu, 30 Jan 2014, Stuart Kendrick via RT wrote: Show quoted text
> ===================================== > $ cat ./test.plx > #!/usr/bin/perl > use strict; > use warnings; > use feature 'say'; > use DateTime; > > my ($dt, $epoch); > $dt = DateTime->new( > year => 2014, > month => 1, > day => 30, > hour => 15, > minute => 30, > second => 5, > nanosecond => 4, > time_zone => 'local', > ); > > say $dt; > $epoch = $dt->hires_epoch; > say $epoch; > ======================================== > > > SAMPLE OUTPUT > $ ./test > 2014-01-30T15:30:05 > 1391124605 > $ > > ==> I would have expected 1391124605.000000004
It looks like this is a floating point precision problem. Internally, DateTime adds the integer epoch to "$nanoseconds / 1_000_000_000". This produces 4e-09. When that is added to a large number, I think it ends up getting floating point imprecisioned away. If you do this with 1970-01-01 you see the nanoseconds in the output (at least on my machine). I don't know that there's any way around this. However, if you're only interested in printing this for someone to read, you can write: say $dt->strftime('%s.%N'); This is a bit ridiculous, but I can't make Perl do math it doesn't want to do with pulling in something like BigFloat, which I'd rather not do. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
Subject: Re: [rt.cpan.org #92594] epoch_hires is not reporting nanoseconds
Date: Sat, 1 Feb 2014 08:02:32 -0800
To: bug-DateTime [...] rt.cpan.org
From: Stuart Kendrick <stuart.kendrick.sea [...] gmail.com>
Thank you for the explanation. And thanx for the tip: the "$dt->strftime('%s.%N')" approach solves my problem rather neatly. --sk On Thu, Jan 30, 2014 at 3:42 PM, autarch@urth.org via RT <bug-DateTime@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=92594 > > > On Thu, 30 Jan 2014, Stuart Kendrick via RT wrote: >
>> ===================================== >> $ cat ./test.plx >> #!/usr/bin/perl >> use strict; >> use warnings; >> use feature 'say'; >> use DateTime; >> >> my ($dt, $epoch); >> $dt = DateTime->new( >> year => 2014, >> month => 1, >> day => 30, >> hour => 15, >> minute => 30, >> second => 5, >> nanosecond => 4, >> time_zone => 'local', >> ); >> >> say $dt; >> $epoch = $dt->hires_epoch; >> say $epoch; >> ======================================== >> >> >> SAMPLE OUTPUT >> $ ./test >> 2014-01-30T15:30:05 >> 1391124605 >> $ >> >> ==> I would have expected 1391124605.000000004
> > It looks like this is a floating point precision problem. Internally, > DateTime adds the integer epoch to "$nanoseconds / 1_000_000_000". This > produces 4e-09. When that is added to a large number, I think it ends up > getting floating point imprecisioned away. > > If you do this with 1970-01-01 you see the nanoseconds in the output (at > least on my machine). > > I don't know that there's any way around this. However, if you're only > interested in printing this for someone to read, you can write: > > say $dt->strftime('%s.%N'); > > This is a bit ridiculous, but I can't make Perl do math it doesn't want to > do with pulling in something like BigFloat, which I'd rather not do. > > > -dave > > /*============================================================ > http://VegGuide.org http://blog.urth.org > Your guide to all that's veg House Absolute(ly Pointless) > ============================================================*/ >
I added a note about this to the docs in the latest release.