Bug #89369 for Date-Manip: ParseDate hole

Wed Oct 09 14:06:00 2013 gene.nardi [...] gmail.com - Ticket created

Subject:	ParseDate hole
Date:	Wed, 9 Oct 2013 11:05:46 -0700
To:	bug-Date-Manip [...] rt.cpan.org
From:	Gene Nardi <gene.nardi [...] gmail.com>

First, Date::Manip is a fine product. I'm trying to migrate to 6.xx and seem to have found a one hour hole in ParseDate ParseDate('4/7/2002 02:00:00') does not parse ParseDate('4/7/2002 01:00:00') does parse ParseDate('4/7/2002 03:00:00') does parse Using perl 5.10.1 Date::Manip 6.38 and 6.41 of course 5.48 under perl 5.10.0 works just fine Thanks Gene Nardi

Wed Oct 09 14:27:23 2013 sbeck [...] cpan.org - Correspondence added

You didn't tell me what timezone you're running in, so I can't verify this... but I'll bet you that 4/7/2002 02:00:00 is the time on which the spring DST transition occurs (meaning that the time 02:00:00 does NOT exist... it goes from 01:59:59 to 03:00:00). So, the fact that the date is parseable in Date::Manip 5.xx is really a bug in the old version. The new version handles it correctly.

Wed Oct 09 14:27:23 2013 The RT System itself - Status changed from 'new' to 'open'

Wed Oct 09 14:27:24 2013 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Oct 09 14:44:28 2013 gene.nardi [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #89369] ParseDate hole
Date:	Wed, 9 Oct 2013 11:44:17 -0700
To:	bug-Date-Manip [...] rt.cpan.org
From:	Gene Nardi <gene.nardi [...] gmail.com>

Seems quite plausible. I'm working with legacy data from Tandem system. I am in the Pacific Time zone. If it is the data I will devise a workaround. Thanks again On Wed, Oct 9, 2013 at 11:27 AM, Sullivan Beck via RT < bug-Date-Manip@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=89369 > > > You didn't tell me what timezone you're running in, so I can't verify > this... > > but I'll bet you that 4/7/2002 02:00:00 is the time on which the spring > DST transition occurs (meaning that the time 02:00:00 does NOT exist... it > goes from 01:59:59 to 03:00:00). > > So, the fact that the date is parseable in Date::Manip 5.xx is really a > bug in the old version. The new version handles it correctly. > >

Wed Oct 09 15:59:14 2013 sbeck [...] cpan.org - Correspondence added

You can always use the unix 'zdump' utility (and Date::Manip comes with an equivalent utility dm_zdump) to check the critical dates in whatever timezone you're working with. Since it IS a change, a well-configured system should never have produced that date. If it did... well, you will need to figure out how you want to interpret them knowing that they are invalid. One possibility would be to work in the UTC timezone which will ignore all DST transitions. That may be the easiest thing to do.

Wed Oct 09 17:13:16 2013 gene.nardi [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #89369] ParseDate hole
Date:	Wed, 9 Oct 2013 14:12:56 -0700
To:	"bug-Date-Manip [...] rt.cpan.org" <bug-Date-Manip [...] rt.cpan.org>
From:	Gene Nardi <gene.nardi [...] gmail.com>

Thanks for the help. This a problem working with data from ancient systems. I be investigating further to see how big the problem is and how robust the workaround needs to be. Like I said earlier. Date::Manip is a really nice product. Gene Sent from my iPhone On 09/ott/2013, at 12:59, "Sullivan Beck via RT" <bug-Date-Manip@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=89369 > > > You can always use the unix 'zdump' utility (and Date::Manip comes with an equivalent utility dm_zdump) to check the critical dates in whatever timezone you're working with. > > Since it IS a change, a well-configured system should never have produced that date. If it did... well, you will need to figure out how you want to interpret them knowing that they are invalid. > > One possibility would be to work in the UTC timezone which will ignore all DST transitions. That may be the easiest thing to do. >