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: Parse has no description of what errors it can generate #32820

weregamer opened this issue Jun 27, 2019 · 1 comment


None yet
3 participants
Copy link

commented Jun 27, 2019

go version go1.12.5 linux/amd64

This is a comment on the current godoc at This godoc does not offer any description of what is or is not an error in parsing.

Some possible errors are pretty obvious - out of range elements, for example (day of year 400, month 13, etc.)

And I do think it's reasonable to expect that you'll get an error if the string doesn't match up very well with the layout you gave (two-digit year instead of four, mismatched punctuation, etc.). But for most packages we seem to be more thorough in explaining border-case errors.

For example, what if the input string has some trailing stuff after the part to be parsed? One could argue that this is a mismatch of the format, and should be an error, or that this is something that should be let slide because you might be parsing just the beginning of a string. Again, I would interpolate the former and expect the caller to do some massaging, but it seems unwise to not be explicit.

@ianlancetaylor ianlancetaylor changed the title time.Parse has no description of what errors it can generate time: Parse has no description of what errors it can generate Jun 27, 2019

@ianlancetaylor ianlancetaylor added this to the Go1.14 milestone Jun 27, 2019


This comment has been minimized.

Copy link

commented Jul 10, 2019

There are currently no tests of the time.Parse method that test error cases. Documenting the failure cases of the current implementation is in affect extending the API to include those failure cases. By my way of thinking that means tests would also need to be added to cover the now-documented failure cases.

I am happy to do any work needed for this. But I would like clarification on the above before I begin.

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