HTTP::Date problems with dates after 3/12/2014 [rt.cpan.org #94151]

[oalders]

Migrated from rt.cpan.org#94151 (status was 'open')

Requestors:

• [email protected]

From [email protected] on 2014-03-24 18:22:36
:

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

[email protected]<mailto:[email protected]>

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.

From [email protected] on 2014-03-24 18:32:43
:

confirmed on OSX, perl 5.19.9, HTTP::Date 6.02. Marking as critical until this can be diagnosed further.

From [email protected] on 2014-03-24 19:06:36
:

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

[email protected]

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:[email protected]] 
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.

From [email protected] on 2014-03-24 19:15:11
:

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

[email protected]

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: Engberg, Eric 
Sent: Monday, March 24, 2014 12:06 PM
To: '[email protected]'
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

[email protected]

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:[email protected]] 
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.

From [email protected] on 2014-03-24 20:06:21
:

On Mon, Mar 24, 2014 at 03:15:12PM -0400, [email protected] 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.

From [email protected] on 2018-02-21 19:57:45
:

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:
> On Mon, Mar 24, 2014 at 03:15:12PM -0400, [email protected]
> 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.