Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time: document that time.Parse using time.RFC822/RFC1123 does not accept all possible 822/1123 times #14505

Closed
Ecsy opened this issue Feb 25, 2016 · 8 comments

Comments

Projects
None yet
6 participants
@Ecsy
Copy link

commented Feb 25, 2016

Probably all golang versions are affected (any os and arch combination).

https://www.ietf.org/rfc/rfc822.txt
2.4.  *RULE:  REPETITION

          The character "*" preceding an element indicates repetition.
     The full form is:

                              <l>*<m>element

     indicating at least <l> and at most <m> occurrences  of  element.

RFC822 date = 1*2DIGIT month 2DIGIT
expected to work:

"4 Feb 09 21:00 PST"
"04 Feb 09 21:00 PST"

actually working:

"04 Feb 09 21:00 PST"

RFC1123 date = 1*2DIGIT month 2*4DIGIT
expected to work:

"Wed, 4 Feb 09 21:00:57 PST"
"Wed, 4 Feb 2009 21:00:57 PST"
"Wed, 04 Feb 2009 21:00:57 PST"

actually working:

"Wed, 04 Feb 2009 21:00:57 PST"

These examples also apply to the Z version constants (with numeric zone).

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2016

I assume you are referring to using them with time.Parse. I think we should just document this.

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Feb 25, 2016

@Ecsy

This comment has been minimized.

Copy link
Author

commented Feb 25, 2016

Sorry to leave that out, yes I was referring to time.Parse.
A particular use case would be the following.
Java generates the following date:

ZonedDateTime now = ZonedDateTime.of(LocalDateTime.of(2009, Month.FEBRUARY, 4, 21, 0, 57), ZoneId.of("UTC"));
String javaDateTimeRFC1123 = now.format(DateTimeFormatter.RFC_1123_DATE_TIME);
// javaDateTimeRFC1123 = "Wed, 4 Feb 2009 21:00:57 GMT"

Parsing this in go:

t, err := time.Parse(time.RFC1123, "Wed, 4 Feb 2009 21:00:57 GMT")
// expected
// err = nil
// t = 2009-02-04 21:00:57 +0000 GMT

// actual
// err = parsing time "Wed, 4 Feb 2009 21:00:57 GMT" as "Mon, 02 Jan 2006 15:04:05 MST": cannot parse "4 Feb 2009 21:00:57 GMT" as "02"
// t = 0001-01-01 00:00:00 +0000 UTC

I do not see it as just a documentation issue, to me it seems that golang do not respects the RFC's actual directive on date.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2016

I see it as a documentation issue because those constants were named with printing in mind, rather than formatting. But if we can address this without changing the printing behavior, I'm OK with that.

@Ecsy

This comment has been minimized.

Copy link
Author

commented Feb 26, 2016

- RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
+ RFC1123 = "Mon, 2 Jan 2006 15:04:05 MST"

Solves the day parsing issue and formatting is still RFC compliant.

- RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
+ RFC1123 = "Mon, 2 Jan 06 15:04:05 MST"

From parsing perspective this would be the fully RFC compliant version, however the Time.parse line 783 case stdYear part fails to parse year correctly with length greater than 2. Fixing that would break RFC822's year, since it only accepts year with length of 2. Maybe a new notation could solve the year problem, which accepts year with length of 2 or 4 and formats year with 4 digits.

RFC822 on the other hand can be easily fixed, since it has the day issue only.

- RFC822 = "02 Jan 06 15:04 MST"
- RFC822Z = "02 Jan 06 15:04 -0700"
+ RFC822 = "2 Jan 06 15:04 MST"
+ RFC822Z = "2 Jan 06 15:04 -0700"
@rsc

This comment has been minimized.

Copy link
Contributor

commented May 18, 2016

We cannot change these constants as suggested.
That will change the output of t.Format(time.RFC1123).

If we need to add separate constant strings time.RFC1123X and time.RFC822X we could do that, but even there it seems silly. For parsing those times you probably want custom code anyway since there are so many special cases.

We can document that strictly speaking Parse(time.RFC822) and 1123 don't admit all possible 822 and 1123 times.

@rsc rsc changed the title time: RFC1123 and RFC822 misunderstood time: document that time.Parse using time.RFC822/RFC1123 does not accept all possible 822/1123 times May 18, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 19, 2016

For completeness, since I didn't see it mentioned, even if it's slightly gross: we could keep the time.RFC822 and time.RFC1123 constants unchanged, and make Parse recognize them, going into specialized parsers for those formats. Yes, that would make them more special. But we could also just document that.

@quentinmit quentinmit added the NeedsFix label May 26, 2016

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 27, 2016

I have no interest in making Parse recognize magic strings. Again, for parsing those times you probably want custom code anyway since there are so many special cases.

@rsc rsc modified the milestones: Go1.7Maybe, Go1.7 May 27, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Jun 9, 2016

CL https://golang.org/cl/23922 mentions this issue.

@gopherbot gopherbot closed this in 894803c Jun 9, 2016

@golang golang locked and limited conversation to collaborators Jun 9, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.