You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a playground link with more examples demonstrating this issue.
The playground link uses now.Parse() and now.MustParse(). The return output consists of two parts.
The first part uses now.Parse(), with time.Now() as reference.
The second part uses now.MustParse(). using the n from your testcase as reference.
Actual playground output (notice the hour and minute):
2009-11-10 23:00:00 +0000 UTC m=+0.000000001
2021-07-20 23:59:10 +0000 UTC
2021-07-20 23:00:10 +0000 UTC
2013-11-18 17:51:49.123456789 +0000 UTC
2002-10-12 17:14:56 +0000 UTC
2002-10-12 17:51:56 +0000 UTC
The expected playground output should be:
2009-11-10 23:00:00 +0000 UTC m=+0.000000001
2021-07-20 00:59:10 +0000 UTC
2021-07-20 00:00:10 +0000 UTC
2013-11-18 17:51:49.123456789 +0000 UTC
2002-10-12 00:14:56 +0000 UTC
2002-10-12 00:00:56 +0000 UTC
Description
When parsing 2006-01-02T15:04:05Z (2006-01-02T15:04:05Z07:00 is also affected as tested), the resulted time is incorrect (see the playground output above).
If the time part is 00:00:00 it works as intended.
If hour and minute are both 00 but second is nonzero, the current hour and minute (or the hour and minute specified in n) will be used instead.
If hour is 00 but minute is nonzero (second doesn't matter), the current hour will be used instead.
I originally posted about this in the now-closed issue #22 as follow-up, but I'm yet to see any change or fix. As a result, I have switched back to the time.Parse() method to process time strings and removed all references to this package (refactored a good amount of code in the progress). A side effect would be that users must now explicitly configure the time format the data use, as time.Parse() requires a time format whereas now.Parse() does not.
PS: Issue #22 (9003839) did fix this issue for time format 2006-01-02 15:04:05, though, as existing test cases (which covered it) are passing.
The text was updated successfully, but these errors were encountered:
Reproducible Example
See this comment.
Here's a playground link with more examples demonstrating this issue.
The playground link uses
now.Parse()
andnow.MustParse()
. The return output consists of two parts.The first part uses
now.Parse()
, withtime.Now()
as reference.The second part uses
now.MustParse()
. using then
from your testcase as reference.Actual playground output (notice the hour and minute):
The expected playground output should be:
Description
When parsing
2006-01-02T15:04:05Z
(2006-01-02T15:04:05Z07:00
is also affected as tested), the resulted time is incorrect (see the playground output above).00:00:00
it works as intended.00
but second is nonzero, the current hour and minute (or the hour and minute specified inn
) will be used instead.00
but minute is nonzero (second doesn't matter), the current hour will be used instead.I originally posted about this in the now-closed issue #22 as follow-up, but I'm yet to see any change or fix. As a result, I have switched back to the
time.Parse()
method to process time strings and removed all references to this package (refactored a good amount of code in the progress). A side effect would be that users must now explicitly configure the time format the data use, astime.Parse()
requires a time format whereasnow.Parse()
does not.PS: Issue #22 (9003839) did fix this issue for time format
2006-01-02 15:04:05
, though, as existing test cases (which covered it) are passing.The text was updated successfully, but these errors were encountered: