Skip Menu |
 

This queue is for tickets about the TimeDate CPAN distribution.

Report information
The Basics
Id: 113726
Status: open
Priority: 0/
Queue: TimeDate

People
Owner: Nobody in particular
Requestors: sebastianokur [...] gmail.com
Cc:
AdminCc:

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



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>
Download (untitled) / with headers
text/plain 864b
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
Download (untitled) / with headers
text/plain 1.1k
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.
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. > > >
Download (untitled) / with headers
text/plain 2.7k
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. > > > > > >
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>
Download (untitled) / with headers
text/plain 3.3k
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.
> > >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.