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

[Ecsy]

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]

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

[Ecsy]

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]

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]

- 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]

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.

[bradfitz]

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.

[rsc]

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.

[gopherbot]

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