Can you suggest how the documentation should be changed? Thanks.

I haven't looked into this fully, but I know that the behaviour pre CL 353713 caused some such inputs to time.Parse() to return an error. Post CL 353713, there is no error for those same inputs. Which begs the question for those people who previously saw/relied on the error, what is the behaviour now?

My only suggestion therefore would be to add some appropriate wording to https://pkg.go.dev/time@go1.18beta1#Parse that explains the new behaviour.

As I mentioned above, I very much defer to you/others on whether this change in behaviour warrants a mention in the release notes that references the https://pkg.go.dev/time@go1.18beta1#Parse docs I propose.

Here is an example that causes an error with Go 1.17:

	fmt.Println(time.Parse(time.RFC3339, "2021-09-29T16:04:33.100000000001Z"))

With Go 1.17 this prints

0001-01-01 00:00:00 +0000 UTC parsing time "2021-09-29T16:04:33.100000000001Z": fractional second out of range

With Go tip this prints

2021-09-29 16:04:33.1 +0000 UTC <nil>

This seems clearly better. But I don't know how to document this except to say something like "fractional seconds that are too small to represent in a Time value are ignored." Does that seem like a useful addition?

To put it another way, to me this seems to be clearly a bug fix. It's difficult for me to imagine that anybody relied on the error they got from using 10 or more digits in the fractional part. Especially since this, for example, does not give an error with Go 1.17, but instead returns the wrong result.

	fmt.Println(time.Parse(time.RFC3339, "2021-09-29T16:04:33.000100000001Z"))

1.17:

2021-09-29 16:04:33.100000001 +0000 UTC <nil>

tip:

2021-09-29 16:04:33.0001 +0000 UTC <nil>

But I don't know how to document this except to say something like "fractional seconds that are too small to represent in a Time value are ignored." Does that seem like a useful addition?

Yes, something like that would work well.

To put it another way, to me this seems to be clearly a bug fix.

Agreed.

It's difficult for me to imagine that anybody relied on the error they got from using 10 or more digits in the fractional part. Especially since this...

Good point, thanks for that example.

The small doc change still seems worthwhile to my mind, but I totally defer to your judgement, especially with the 1.18 release not far away.

I see this as a bug fix rather than a behavior change as such, so I don't think it needs to be explicitly called out in the release notes.

I'll send a patch for the docs.

Change https://golang.org/cl/381155 mentions this issue: time: document that Parse truncates to nanosecond precision

I see this as a bug fix rather than a behavior change as such, so I don't think it needs to be explicitly called out in the release notes.

👍

I'll send a patch for the docs.

I just +1-ed. I'll defer to someone who owns the package to +2.