Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
time: document that time.Parse using time.RFC822/RFC1123 does not accept all possible 822/1123 times #14505
Probably all golang versions are affected (any os and arch combination).
These examples also apply to the Z version constants (with numeric zone).
Sorry to leave that out, yes I was referring to time.Parse.
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.
Solves the day parsing issue and formatting is still RFC compliant.
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.
We cannot change these constants as suggested.
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.
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.