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.

Sign up for GitHub

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

Jump to bottom

time: Parse should handle Jan 2nd #28841

Closed
seebs opened this issue Nov 17, 2018 · 9 comments
Closed

time: Parse should handle Jan 2nd #28841

seebs opened this issue Nov 17, 2018 · 9 comments
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@seebs
Copy link
Contributor

seebs commented Nov 17, 2018

What version of Go are you using (go version)?

$ go version
1.11

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"

What did you do?

used a layout: Jan 2nd, '06
to parse a time: Jan 3rd, '06

What did you expect to see?

Ideally, I would love it if this worked.

What did you see instead?

It can't parse rd, ' as nd, '.

I'm well aware that this may well be a ridiculous edge case, but it seems to me that the specific idiom of writing the weird suffixes on numbers in dates is fairly common, and it's very hard for a naive user, or even a moderately skilled one, to discern correctly where in a string to look for such a suffix.

The reference time makes it possible to reasonably infer that 2nd implies the format "day of month plus suffix". Given that, it would be reasonably practical to do either of (1) accepting the correct suffixes for the 31 values which can reasonably occur, or (2) accepting any of st/nd/rd/th after a numeric day value. (Given the response to #12728, I'm guessing that the latter would be preferable; this is arguably less of an error than feb 30th is...)

I'm honestly not sure it's a good idea. On the other hand, I think the risk is very low -- I doubt anyone has ever written a layout with 2nd in it with the intent that it match explicitly only the literal nd, or produce nd after every number, and getting it right would look really cool.

Being prone to hubris, I'm totally volunteering to try to write this if anyone expresses a willingness to see it merged.
@ianlancetaylor ianlancetaylor changed the title time.Parse should handle Jan 2nd time: Parse should handle Jan 2nd Nov 17, 2018
@ianlancetaylor
Copy link
Member

Could you show a small, complete, example program, perhaps on play.golang.org? Thanks.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 17, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Nov 17, 2018
@seebs
Copy link
Contributor Author

seebs commented Nov 17, 2018

https://play.golang.org/p/uF6c0kO-3ow

D'oh, sorry about that. I even had the window still open. :)

@ianlancetaylor
Copy link
Member

Thanks. I see. I would worry about internationalization. Matching "Jan" is one thing, matching "2nd" is another. Do we really want to only match these English abbreviations? I don't think we want to support every language. This can be done outside of the standard library, and that might be best.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/150137 mentions this issue: time: parse dates using textual suffixes like "nd"

@seebs
Copy link
Contributor Author

seebs commented Nov 17, 2018

Hmm. Does time.Parse handle non-English month names? I was under the impression it only handled English at the moment.

I agree that it might be a bad idea to handle this partially, but it turned out to be easy to write, so I've sent in the code. I will not be in the slightest offended if it's rejected.

@bradfitz bradfitz added the FeatureRequest Issues asking for a new feature that does not need a proposal. label Nov 20, 2018
@rsc
Copy link
Contributor

rsc commented Jan 25, 2019

This seems like overreach to me. I'm inclined not to.

/cc @robpike

@seebs
Copy link
Contributor Author

seebs commented Jan 25, 2019

I'm honestly still not sure how I feel about it. It's way easier than I originally thought it would be, but it's not at all obvious that it's desireable. The big appeal is just that it's a reasonably common written date format.

@robpike
Copy link
Contributor

robpike commented Jan 25, 2019

This does feel like overreach. Internationalization worries abound as well.

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@ALTree
Copy link
Member

ALTree commented Dec 4, 2019

There seems to be a consensus that we won't be supporting this, so I think we can close this issue.

@ALTree ALTree closed this as completed Dec 4, 2019
@golang golang locked and limited conversation to collaborators Dec 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
8 participants
@bradfitz @rsc @seebs @andybons @ianlancetaylor @ALTree @robpike @gopherbot