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: 92655
Status: resolved
Priority: 0/
Queue: DateTime
People
Owner: Nobody in particular
Requestors: lloyd.fourn [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.09

History Show all quoted text
  Sun Feb 02 09:06:28 2014 lloyd.fourn [...] gmail.com - Ticket created
Subject: from_epoch freezes program if epoch is milliseconds instead of seconds
Date: Sun, 2 Feb 2014 22:06:20 +0800
To: bug-DateTime [...] rt.cpan.org
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
DateTime->from_epoch(epoch => 1391000488000, time_zone => 'Australia/Sydney') seems to freeze the program. (it doesn't fail if there is no time_zone)
  Sun Feb 02 11:34:53 2014 autarch [...] urth.org - Correspondence added
Subject: Re: [rt.cpan.org #92655] from_epoch freezes program if epoch is milliseconds instead of seconds
Date: Sun, 2 Feb 2014 10:34:43 -0600 (CST)
To: Lloyd Fournier via RT <bug-DateTime [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Sun, 2 Feb 2014, Lloyd Fournier via RT wrote: Show quoted text
> Sun Feb 02 09:06:28 2014: Request 92655 was acted upon. > Transaction: Ticket created by M0ast > Queue: DateTime > Subject: from_epoch freezes program if epoch is milliseconds instead of seconds > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: lloyd.fourn@gmail.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=92655 > > > > DateTime->from_epoch(epoch => 1391000488000, time_zone => > 'Australia/Sydney') > > seems to freeze the program. (it doesn't fail if there is no time_zone)
If you waited long enough it'd complete. The issue is that it has to calculate DST changes all for about 44,000 years, and that's going to take a while. This will be fixed when we switch to DateTime::TimeZone 2.0. But regardless, what you're doing doesn't make any sense. Time zones don't really apply to far future dates, unless you expect the Australian government to be around 44,000 years from now. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
  Sun Feb 02 11:34:54 2014 The RT System itself - Status changed from 'new' to 'open'
  Sun Feb 02 12:59:17 2014 ether [...] cpan.org - Correspondence added
It would probably make sense to issue a warning immediately when handed an epoch that is very much outside the normal range (e.g. past 2038, earlier than 1969). You could even invent a new warning category for this so the user can suppress it.
  Sun Feb 02 13:31:20 2014 lloyd.fourn [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #92655] from_epoch freezes program if epoch is milliseconds instead of seconds
Date: Mon, 3 Feb 2014 02:31:08 +0800
To: bug-DateTime [...] rt.cpan.org
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
Ah that makes sense. I was using Mango::BSON::Time without the ->to_epoch, so was getting milliseconds epoch. Sorry for the bother. On a side note, I expect 44,000 years in the future all Humans will be dead or we will have evolved to a point where we don't need rulers. We may have even evolved past perl 5 by then. On Mon, Feb 3, 2014 at 12:34 AM, autarch@urth.org via RT < bug-DateTime@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=92655 > > > On Sun, 2 Feb 2014, Lloyd Fournier via RT wrote: >
> > Sun Feb 02 09:06:28 2014: Request 92655 was acted upon. > > Transaction: Ticket created by M0ast > > Queue: DateTime > > Subject: from_epoch freezes program if epoch is milliseconds instead
> of seconds
> > Broken in: (no value) > > Severity: (no value) > > Owner: Nobody > > Requestors: lloyd.fourn@gmail.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=92655 > > > > > > > DateTime->from_epoch(epoch => 1391000488000, time_zone => > > 'Australia/Sydney') > > > > seems to freeze the program. (it doesn't fail if there is no time_zone)
> > If you waited long enough it'd complete. The issue is that it has to > calculate DST changes all for about 44,000 years, and that's going to take > a while. > > This will be fixed when we switch to DateTime::TimeZone 2.0. But > regardless, what you're doing doesn't make any sense. Time zones don't > really apply to far future dates, unless you expect the Australian > government to be around 44,000 years from now. > > > -dave > > /*============================================================ > http://VegGuide.org http://blog.urth.org > Your guide to all that's veg House Absolute(ly Pointless) > ============================================================*/ > >
  Sun Feb 02 13:41:46 2014 DROLSKY [...] cpan.org - Correspondence added
On Sun Feb 02 13:31:20 2014, M0ast wrote: Show quoted text
> Ah that makes sense. I was using Mango::BSON::Time without the ->to_epoch, > so was getting milliseconds epoch. > Sorry for the bother. > On a side note, I expect 44,000 years in the future all Humans will be dead > or we will have evolved to a point where we don't need rulers. We may have > even evolved past perl 5 by then.
I'm pretty sure Perl 6 will have come out the Christmas just before then, so yes.
  Sun May 04 00:06:47 2014 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'
  Sun May 04 00:06:47 2014 DROLSKY [...] cpan.org - Fixed in 1.09 added