Bug #113726 for TimeDate: str2time parses incorrectly.

Tue Apr 12 20:43:54 2016 sebastianokur [...] gmail.com - Ticket created

Subject:	str2time parses incorrectly.
Date:	Tue, 12 Apr 2016 20:43:43 -0400
To:	bug-TimeDate [...] rt.cpan.org
From:	Sebastian Okur <sebastianokur [...] gmail.com>

Hi, As much as I can see from the documentation, there is no information regarding to inability to parse "YYYY-MM-DD hh:mm:ss.SSS" format. Also, I noticed it is mentioned that the str2time function should return undef if it doesn't support string for parsing. Below is the code and its output: *===* #!/usr/bin/perl use strict; use warnings; use Date::Parse; my $date1_str = "2016-01-28 23:27:13,995"; my $date1_epoch = str2time($date1_str); print "date1_epoch: [$date1_epoch]\n"; my $date2_str = "2016-01-28 23:27:13,996"; my $date2_epoch = str2time($date2_str); print "date2_epoch: [$date2_epoch]\n"; # OUTPUT: # # date1_epoch: [1453985533] # date2_epoch: [1453985473] *===* Notice that *date2_epoch* is earlier than *date1_epoch*, and –if anything– epoch values should be the same. Thanks for your time and assistance in advance, --Sebastian Okur

Wed Apr 13 02:45:19 2016 SREZIC [...] cpan.org - Correspondence added

On 2016-04-12 20:43:54, sebastianokur@gmail.com wrote: Show quoted text

> Hi, > > As much as I can see from the documentation, there is no information > regarding to inability to parse "YYYY-MM-DD hh:mm:ss.SSS" format. Also, I > noticed it is mentioned that the str2time function should return undef if > it doesn't support string for parsing. > > Below is the code and its output: > > *===* > #!/usr/bin/perl > > use strict; > use warnings; > use Date::Parse; > > my $date1_str = "2016-01-28 23:27:13,995"; > my $date1_epoch = str2time($date1_str); > print "date1_epoch: [$date1_epoch]\n"; > > my $date2_str = "2016-01-28 23:27:13,996"; > my $date2_epoch = str2time($date2_str); > print "date2_epoch: [$date2_epoch]\n"; > > # OUTPUT: > # > # date1_epoch: [1453985533] > # date2_epoch: [1453985473] > *===* > > Notice that *date2_epoch* is earlier than *date1_epoch*, and –if anything– > epoch values should be the same. > > Thanks for your time and assistance in advance, > > --Sebastian Okur

Actually, if the comma in the test script is replaced with a dot, then things work fine. I wouldn't expect that Date::Parse should parse the comma as a decimal dot.

Wed Apr 13 02:45:20 2016 The RT System itself - Status changed from 'new' to 'open'

Wed Apr 13 11:18:05 2016 sebastianokur [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #113726] str2time parses incorrectly.
Date:	Wed, 13 Apr 2016 11:17:49 -0400
To:	bug-TimeDate [...] rt.cpan.org
From:	Sebastian Okur <sebastianokur [...] gmail.com>

Thanks for the heads up. I already found that out and fixed my code to accommodate it. I guess the point I was trying to make is that *str2time* function silently fails by producing unpredictable results instead of failing hard by returning *undef* for input formats that are not supported or not entirely correct in its form. Since epoch values are scalars that are not as easily distinguishable as other-more readable date formats (*1454023633995* VS *2016-01-28 23:27:13,995*), especially when the first couple of digits are correct, it is not immediately obvious to the developer that the result is wrong. It would be very helpful if functions fail hard in a conspicuous fashion when they fail. On Wed, Apr 13, 2016 at 2:45 AM, Slaven_Rezic via RT < bug-TimeDate@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=113726 > > > On 2016-04-12 20:43:54, sebastianokur@gmail.com wrote:

> > Hi, > > > > As much as I can see from the documentation, there is no information > > regarding to inability to parse "YYYY-MM-DD hh:mm:ss.SSS" format. Also, I > > noticed it is mentioned that the str2time function should return undef if > > it doesn't support string for parsing. > > > > Below is the code and its output: > > > > *===* > > #!/usr/bin/perl > > > > use strict; > > use warnings; > > use Date::Parse; > > > > my $date1_str = "2016-01-28 23:27:13,995"; > > my $date1_epoch = str2time($date1_str); > > print "date1_epoch: [$date1_epoch]\n"; > > > > my $date2_str = "2016-01-28 23:27:13,996"; > > my $date2_epoch = str2time($date2_str); > > print "date2_epoch: [$date2_epoch]\n"; > > > > # OUTPUT: > > # > > # date1_epoch: [1453985533] > > # date2_epoch: [1453985473] > > *===* > > > > Notice that *date2_epoch* is earlier than *date1_epoch*, and –if

> anything–

> > epoch values should be the same. > > > > Thanks for your time and assistance in advance, > > > > --Sebastian Okur

> > Actually, if the comma in the test script is replaced with a dot, then > things work fine. I wouldn't expect that Date::Parse should parse the comma > as a decimal dot. > > >

Thu Apr 14 14:42:44 2016 SREZIC [...] cpan.org - Correspondence added

I did some debugging what's going on here. An early transformation replaces all commas into spaces, so we get something like "2016-01-28 23:27:13 995". If the bit behind the seconds looks vaguely like a timezone specification, then it seems that it's used as one. In this case this means an offset of 9 hours and 95 minutes, which is causing the difference. Probably everything >= 60 minutes could generate an error here. It would probably also be good to improve the comma replacement, maybe don't do it all over the place. On 2016-04-13 11:18:05, sebastianokur@gmail.com wrote: Show quoted text

> Thanks for the heads up. I already found that out and fixed my code to > accommodate it. > > I guess the point I was trying to make is that *str2time* function > silently > fails by producing unpredictable results instead of failing hard by > returning *undef* for input formats that are not supported or not > entirely > correct in its form. > > Since epoch values are scalars that are not as easily distinguishable > as > other-more readable date formats (*1454023633995* VS *2016-01-28 > 23:27:13,995*), especially when the first couple of digits are > correct, it > is not immediately obvious to the developer that the result is wrong. > > It would be very helpful if functions fail hard in a conspicuous > fashion > when they fail. > > > On Wed, Apr 13, 2016 at 2:45 AM, Slaven_Rezic via RT < > bug-TimeDate@rt.cpan.org> wrote: >

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=113726 > > > > > On 2016-04-12 20:43:54, sebastianokur@gmail.com wrote:

> > > Hi, > > > > > > As much as I can see from the documentation, there is no > > > information > > > regarding to inability to parse "YYYY-MM-DD hh:mm:ss.SSS" format. > > > Also, I > > > noticed it is mentioned that the str2time function should return > > > undef if > > > it doesn't support string for parsing. > > > > > > Below is the code and its output: > > > > > > *===* > > > #!/usr/bin/perl > > > > > > use strict; > > > use warnings; > > > use Date::Parse; > > > > > > my $date1_str = "2016-01-28 23:27:13,995"; > > > my $date1_epoch = str2time($date1_str); > > > print "date1_epoch: [$date1_epoch]\n"; > > > > > > my $date2_str = "2016-01-28 23:27:13,996"; > > > my $date2_epoch = str2time($date2_str); > > > print "date2_epoch: [$date2_epoch]\n"; > > > > > > # OUTPUT: > > > # > > > # date1_epoch: [1453985533] > > > # date2_epoch: [1453985473] > > > *===* > > > > > > Notice that *date2_epoch* is earlier than *date1_epoch*, and –if

> > anything–

> > > epoch values should be the same. > > > > > > Thanks for your time and assistance in advance, > > > > > > --Sebastian Okur

> > > > Actually, if the comma in the test script is replaced with a dot, > > then > > things work fine. I wouldn't expect that Date::Parse should parse the > > comma > > as a decimal dot. > > > > > >

Thu Apr 14 20:48:08 2016 sebastianokur [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #113726] str2time parses incorrectly.
Date:	Thu, 14 Apr 2016 20:47:57 -0400
To:	bug-TimeDate [...] rt.cpan.org
From:	Sebastian Okur <sebastianokur [...] gmail.com>

It might be better to match the regex based on supported formats and overload the missing time items (milliseconds, time, etc) with default values. Main things is not making the program intelligent in order to make it try and assume what the caller is trying to do. More importantly, making the program fail hard if an input doesn't match any of the supported formats, completely. Show quoted text

> On Apr 14, 2016, at 2:42 PM, Slaven_Rezic via RT <bug-TimeDate@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=113726 > > > I did some debugging what's going on here. An early transformation replaces all commas into spaces, so we get something like "2016-01-28 23:27:13 995". If the bit behind the seconds looks vaguely like a timezone specification, then it seems that it's used as one. In this case this means an offset of 9 hours and 95 minutes, which is causing the difference. > > Probably everything >= 60 minutes could generate an error here. > > It would probably also be good to improve the comma replacement, maybe don't do it all over the place. >

>> On 2016-04-13 11:18:05, sebastianokur@gmail.com wrote: >> Thanks for the heads up. I already found that out and fixed my code to >> accommodate it. >> >> I guess the point I was trying to make is that *str2time* function >> silently >> fails by producing unpredictable results instead of failing hard by >> returning *undef* for input formats that are not supported or not >> entirely >> correct in its form. >> >> Since epoch values are scalars that are not as easily distinguishable >> as >> other-more readable date formats (*1454023633995* VS *2016-01-28 >> 23:27:13,995*), especially when the first couple of digits are >> correct, it >> is not immediately obvious to the developer that the result is wrong. >> >> It would be very helpful if functions fail hard in a conspicuous >> fashion >> when they fail. >> >> >> On Wed, Apr 13, 2016 at 2:45 AM, Slaven_Rezic via RT < >> bug-TimeDate@rt.cpan.org> wrote: >>

>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=113726 > >>>

>>>> On 2016-04-12 20:43:54, sebastianokur@gmail.com wrote: >>>> Hi, >>>> >>>> As much as I can see from the documentation, there is no >>>> information >>>> regarding to inability to parse "YYYY-MM-DD hh:mm:ss.SSS" format. >>>> Also, I >>>> noticed it is mentioned that the str2time function should return >>>> undef if >>>> it doesn't support string for parsing. >>>> >>>> Below is the code and its output: >>>> >>>> *===* >>>> #!/usr/bin/perl >>>> >>>> use strict; >>>> use warnings; >>>> use Date::Parse; >>>> >>>> my $date1_str = "2016-01-28 23:27:13,995"; >>>> my $date1_epoch = str2time($date1_str); >>>> print "date1_epoch: [$date1_epoch]\n"; >>>> >>>> my $date2_str = "2016-01-28 23:27:13,996"; >>>> my $date2_epoch = str2time($date2_str); >>>> print "date2_epoch: [$date2_epoch]\n"; >>>> >>>> # OUTPUT: >>>> # >>>> # date1_epoch: [1453985533] >>>> # date2_epoch: [1453985473] >>>> *===* >>>> >>>> Notice that *date2_epoch* is earlier than *date1_epoch*, and –if

>>> anything–

>>>> epoch values should be the same. >>>> >>>> Thanks for your time and assistance in advance, >>>> >>>> --Sebastian Okur

>>> >>> Actually, if the comma in the test script is replaced with a dot, >>> then >>> things work fine. I wouldn't expect that Date::Parse should parse the >>> comma >>> as a decimal dot.

> > >

Wed Jan 15 16:27:53 2020 me [...] eboxr.com - Correspondence added

Ticket migrated to github as https://github.com/atoomic/perl-TimeDate/issues/35