Hi!
On Mon, Jul 03, 2017 at 10:00:52AM +0200, Binarus wrote:
> My main problem was that from my readings I got the impression that even
> the block eval might be problematic (please see my answer to Thomas
> Klausner's first post if you are interested what made me believe so).
Just for a bit
Hi!
On Sun, Jul 02, 2017 at 11:59:56AM +0200, Binarus wrote:
> - Most people recommend to "catch the error" DateTime throws when
> encountering such date-times, but if I got it right, that always
> involves eval, even when using modules like Try:Tiny and the like, so I
> don't want to do that.
Hi!
On Wed, Jun 27, 2012 at 07:16:06AM +0100, Zefram wrote:
Thomas Klausner wrote:
The only potential deal-breaker is the fact that if you now create a new
DateTime that does not exists, you'll get the next valid time instead of
an exception
Getting an exception in this situation
-:+-$-gprint$_.$/}
From f91bd008dba06bf49a4fa62b34922dae86e37c43 Mon Sep 17 00:00:00 2001
From: Thomas Klausner d...@plix.at
Date: Wed, 27 Jun 2012 02:43:54 +0200
Subject: [PATCH] try to work around nonexistent DST datetimes (incl test)
---
lib/DateTime/TimeZone.pm |8 +
t/22_dst_mess.t
Hi!
On Tue, Apr 24, 2012 at 03:50:27PM +, Carl Vincent wrote:
I'm looking to parse a datetime from ISO8601 use DateTime::Format::ISO8601
2012-04-24T10:39:00.000+
I had a similar problem once:
https://rt.cpan.org/Public/Bug/Display.html?id=52645
(I submitted a patch to RT, even
Hi!
I'm getting strange results when subtracting dates from one another:
I make a new $dt object, setting the date to e.g. 2003-05-31. If I subtract
one month, I do not get 2003-04-30, but 2005-05-01, which seems wrong to me.
This problem only occurs in months with 31 days, exept August, which
Hi!
On Fri, Aug 15, 2003 at 12:53:56PM -0500, Dave Rolsky wrote:
The results are actually consistent with the internal logic, but
definitely surprising for end users.
Surprising, indeed.
If you add end_of_month = 'preserve' it does what you are wanting.
Ah, after reading the docs more
