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: 94377
Status: rejected
Priority: 0/
Queue: DateTime

People
Owner: Nobody in particular
Requestors: karjala [...] karjala.org
Cc:
AdminCc:

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



Subject: Date calculation can return invalid time
In the Europe/Athens timezone, date 2014-03-30 03:30:00 is non-existent, is invalid, because the time jumped then from 03:00:00 directly to 04:00:00. However the following much-used date calculation leads to such an invalid date and causes the program to badly crash. #!/usr/bin/perl use strict; use warnings; use DateTime; my $dt = DateTime->new( year => 2014, month => 3, day => 29, hour => 3, minute => 30, second => 0, time_zone => 'Europe/Athens', ); print $dt, "\n"; print $dt->add(days => 1), "\t"; __END__ That means, that whoever tried to log on to my site on the 29th around 3:30, couldn't access the site.
It also made my mission-critical Cron script to not work until I fixed it 8 hours afterwards.
This is well documented in the module - https://metacpan.org/pod/DateTime#Local-vs.-UTC-and-24-hours-vs.-1-day This isn't a bug, it's just how datetime math works. There a number of ways to work around this. See the docs for more details.
Your module behaves differently on not-very-different situations. In the leap seconds chapter (here: https://metacpan.org/pod/DateTime#Leap-Seconds-and-Date-Math) you say this: Show quoted text
> Then the datetime is now "1973-02-01 00:00:00", because there is no 23:59:60 on 1973-01-31.
So non-existent times get jumped by $dt->add... why not always? Why couldn't the same type of jumping occur when a DST hour doesn't exist?
On Wed Apr 02 10:49:31 2014, KARJALA wrote: Show quoted text
> Your module behaves differently on not-very-different situations. > > In the leap seconds chapter (here: > https://metacpan.org/pod/DateTime#Leap-Seconds-and-Date-Math) you say > this: >
> > Then the datetime is now "1973-02-01 00:00:00", because there is no > > 23:59:60 on 1973-01-31.
> > So non-existent times get jumped by $dt->add... why not always? Why > couldn't the same type of jumping occur when a DST hour doesn't exist?
Again, this is all covered by the docs.
Subject: Re: [rt.cpan.org #94377] Date calculation can return invalid time
Date: Thu, 10 Apr 2014 00:11:31 +0300
To: bug-DateTime [...] rt.cpan.org
From: Alexander Karelas <alex.karelas [...] gmail.com>
I'm going to implement the workaround where I convert the $dt object to UTC first, and then add (and re-convert back afterwards). But I need to do this workaround only when the direct addition causes an exception (so that $today->add(days => 10) will still land on a midnight) So what I'd like to ask is this: if eval { $dt->add(days => 1) } fails with "Invalid time", can I safely assume that $dt will (after this failure) still be identical to what it was before the failed addition? Thanks, - A. On 04/02/2014 05:53 PM, Dave Rolsky via RT wrote: Show quoted text
> Again, this is all covered by the docs.
On Wed Apr 09 17:11:43 2014, alex.karelas@gmail.com wrote: Show quoted text
> I'm going to implement the workaround where I convert the $dt object to > UTC first, and then add (and re-convert back afterwards). > > But I need to do this workaround only when the direct addition causes an > exception (so that $today->add(days => 10) will still land on a midnight) > > So what I'd like to ask is this: if eval { $dt->add(days => 1) } fails > with "Invalid time", can I safely assume that $dt will (after this > failure) still be identical to what it was before the failed addition?
It _should_ keep it the same. If it doesn't that's a bug. I know truncate() has a bug along these lines right now, but I don't think the math operators should have the same problem.