Skip Menu |

This queue is for tickets about the HTTP-Date CPAN distribution.

Report information
The Basics
Id: 94151
Status: resolved
Priority: 0/
Queue: HTTP-Date

People
Owner: Nobody in particular
Requestors: Eric.Engberg [...] wellsfargo.com
Cc:
AdminCc:

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



Subject: HTTP::Date problems with dates after 3/12/2014
Date: Mon, 24 Mar 2014 18:22:16 +0000
To: <bug-HTTP-Date [...] rt.cpan.org>
From: <Eric.Engberg [...] wellsfargo.com>
This may be a duplicate, or at least related to bug 83803 - but I wanted to add some more information. My work is on Windows/ActiveState perl, and I use HTTP::Date a lot to parse time and date strings in to seconds, and then in to other date formats. I find it really useful, and am worried about switching modules or completely updating Perl to solve this issue. I find that dates after 2014-03-12 return undef when I call str2time on them (at least in the following format): I can reproduce this on perl 5.8.8 and 5.12.4 (below). I was using an older Time::Local (1.19), but upgrading to current (1.23) didn't help. If you know of a fix, I'd love to apply it, or I'll research if I can make the change in HTTP::Date locally. ---- D:\Metrics>perl -MHTTP::Date -e "print str2time('3/12/2014 0:00')" 1417593600 D:\Metrics>perl -MHTTP::Date -e "print str2time('3/13/2014 0:00')" D:\Metrics>perl -v This is perl 5, version 12, subversion 4 (v5.12.4) built for MSWin32-x86-multi-thread (with 9 registered patches, see perl -V for more detail) Copyright 1987-2010, Larry Wall Binary build 1205 [294981] provided by ActiveState http://www.ActiveState.com Built Jun 20 2011 18:35:25 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Eric Engberg Business Process Consultant QA & RMS Community Bank Technology MAC Q3604-010 Tel 505 299-6071 eric.engberg@wellsfargo.com<mailto:eddie.park@wellsfargo.com> This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
confirmed on OSX, perl 5.19.9, HTTP::Date 6.02. Marking as critical until this can be diagnosed further.
Subject: RE: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014
Date: Mon, 24 Mar 2014 19:06:22 +0000
To: <bug-HTTP-Date [...] rt.cpan.org>
From: <Eric.Engberg [...] wellsfargo.com>
Thank you very much for confirming the bug. I think I have a solution, and can diagnose that HTTP::Date is working as advertised, but doesn't deal with US style dates in this format. One more piece of information I should have included: the source of this date format is originally excel. It is common US-style date to use Month/Day/Year, like 3/15/2014 (meaning March 15), to the consternation of Europeans who would write the same date as 15/03/2014. From working with the parse_date function in the HTTP::Date module, I think that's the problem: the function expects the European style, and doesn't support the US style. The European style does make more sense, like the Metric system, because the numbers are ordered (least->greatest, day to year), but perhaps the region of the user would be helpful to determine which format is dominant. Since I'm in the US, my suggested fix (which I'll use) is to add this regex with the month/date order changed before the European style: 93a94,114 Show quoted text
> # Give preference to US style (even though it makes less sense mathematically) > (($mon,$day,$yr,$hr,$min,$sec,$tz) = > /^ > (\w+) # month > (?:\s+|[-\/]) > (\d\d?) # day > (?:\s+|[-\/]) > (\d+) # year > (?: > (?:\s+|:) # separator before clock > (\d\d?):(\d\d) # hour:min > (?::(\d\d))? # optional seconds > )? # optional clock > \s* > ([-+]?\d{2,4}|(?![APap][Mm]\b)[A-Za-z]+)? # timezone > \s* > (?:\(\w+\)|\w{3,})? # ASCII representation of timezone. > \s*$ > /x) > > ||
Eric Engberg Business Process Consultant QA & RMS Community Bank Technology MAC Q3604-010 Tel 505 299-6071 eric.engberg@wellsfargo.com This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation. Show quoted text
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-HTTP-Date@rt.cpan.org] Sent: Monday, March 24, 2014 11:33 AM To: Engberg, Eric Subject: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014 <URL: https://rt.cpan.org/Ticket/Display.html?id=94151 > confirmed on OSX, perl 5.19.9, HTTP::Date 6.02. Marking as critical until this can be diagnosed further.
Subject: RE: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014
Date: Mon, 24 Mar 2014 19:14:47 +0000
To: <bug-HTTP-Date [...] rt.cpan.org>
From: <Eric.Engberg [...] wellsfargo.com>
One more thought on my 'fix'/enhancement for US users: It might be worth checking if the month and days look like they are switched, and giving the benefit of the doubt to the user, that if they write 3/15/2014 or 15/3/2014 that in either case they probably mean March 15. # Swap month/day if month is greater than 12 if ($mon > 12 && $day < 12) { ($mon, $day) = ($day, $mon); } This wouldn't help disambiguate whether 4/6/2014 means June or April, unfortunately, which is why I think you have to consider the region to make a guess. Eric Engberg Business Process Consultant QA & RMS Community Bank Technology MAC Q3604-010 Tel 505 299-6071 eric.engberg@wellsfargo.com This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation. Show quoted text
-----Original Message----- From: Engberg, Eric Sent: Monday, March 24, 2014 12:06 PM To: 'bug-HTTP-Date@rt.cpan.org' Subject: RE: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014 Thank you very much for confirming the bug. I think I have a solution, and can diagnose that HTTP::Date is working as advertised, but doesn't deal with US style dates in this format. One more piece of information I should have included: the source of this date format is originally excel. It is common US-style date to use Month/Day/Year, like 3/15/2014 (meaning March 15), to the consternation of Europeans who would write the same date as 15/03/2014. From working with the parse_date function in the HTTP::Date module, I think that's the problem: the function expects the European style, and doesn't support the US style. The European style does make more sense, like the Metric system, because the numbers are ordered (least->greatest, day to year), but perhaps the region of the user would be helpful to determine which format is dominant. Since I'm in the US, my suggested fix (which I'll use) is to add this regex with the month/date order changed before the European style: 93a94,114
> # Give preference to US style (even though it makes less sense mathematically) > (($mon,$day,$yr,$hr,$min,$sec,$tz) = > /^ > (\w+) # month > (?:\s+|[-\/]) > (\d\d?) # day > (?:\s+|[-\/]) > (\d+) # year > (?: > (?:\s+|:) # separator before clock > (\d\d?):(\d\d) # hour:min > (?::(\d\d))? # optional seconds > )? # optional clock > \s* > ([-+]?\d{2,4}|(?![APap][Mm]\b)[A-Za-z]+)? # timezone > \s* > (?:\(\w+\)|\w{3,})? # ASCII representation of timezone. > \s*$ > /x) > > ||
Eric Engberg Business Process Consultant QA & RMS Community Bank Technology MAC Q3604-010 Tel 505 299-6071 eric.engberg@wellsfargo.com This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation.
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-HTTP-Date@rt.cpan.org] Sent: Monday, March 24, 2014 11:33 AM To: Engberg, Eric Subject: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014 <URL: https://rt.cpan.org/Ticket/Display.html?id=94151 > confirmed on OSX, perl 5.19.9, HTTP::Date 6.02. Marking as critical until this can be diagnosed further.
Subject: Re: [rt.cpan.org #94151] HTTP::Date problems with dates after 3/12/2014
Date: Mon, 24 Mar 2014 13:06:05 -0700
To: "Eric.Engberg [...] wellsfargo.com via RT" <bug-HTTP-Date [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Mon, Mar 24, 2014 at 03:15:12PM -0400, Eric.Engberg@wellsfargo.com via RT wrote: Show quoted text
> It might be worth checking if the month and days look like they are switched, and giving the benefit of the doubt to the user, that if they write > 3/15/2014 or 15/3/2014 that in either case they probably mean March 15.
Instead of silently switching, I'd prefer to issue a warning, so the user knwos why they got undef back and can switch their code.
I took a look at this issue to attempt a fix, and I don't think this can be easily done without breaking existing behaviour. I agree that a silent guess is not a good idea. But adding a warning would change documented behaviour, and possibly break code / tests in the distributions that use this as a time validator. Specially considering the position of this module in the river of CPAN, this is a serious concern. I suggest this to be closed. A clarification in the documentation is probably the best solution this can get. On Mon Mar 24 16:06:21 2014, ETHER wrote: Show quoted text
> On Mon, Mar 24, 2014 at 03:15:12PM -0400, Eric.Engberg@wellsfargo.com > via RT wrote:
> > It might be worth checking if the month and days look like they are > > switched, and giving the benefit of the doubt to the user, that if > > they write > > 3/15/2014 or 15/3/2014 that in either case they probably mean March > > 15.
> > Instead of silently switching, I'd prefer to issue a warning, so the > user > knwos why they got undef back and can switch their code.