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 #4001
Labels
Milestone
Comments
To be fair, you're asking to parse EDT not EST and EDT is not a valid time zone for this instant. If you change the program to use EST or choose a date when EDT is in effect you'll find it works. I agree that the behavior isn't right. We may address this in go1.1 by returning an error for an incorrect time zone, as you have here, or correcting by one hour if it's a daylight savings time issue. Underlying all that is the much bigger issue that you're assuming EDT is a known and unambiguous time zone. That's not always true. For instance, the string "20110122EDT" *is* valid in Sydney. However, it should behave better if the local time zone is spelled EST/EDT and that should be fixable. Time zones are hard and also not always decidable. Labels changed: added priority-later, go1.1, removed priority-triage. Status changed to Accepted. |
There are two separate things we could think about changing for Go 1.1. 1. What to do about unknown zone names (like EDT in California)? Right now we record the name but use +0000 as the offset. We could instead return an error from Parse. 2. What to do about known zone names that do not apply to the given time (like January PDT in California)? Right now we record the name but use +0000 as the offset, because athough PDT is known in California, it is not in effect in January, so we treat it as an unknown zone. We could instead record PDT's real offset even though January times are conventionally written in PST, the same way we accept January 32 even though it is conventionally written as February 1. |
I think issue #3385 and issue #3604 are quite similar. There is certainly a possible merge between them. |
In response to the questions laid out in comment #3, I believe we should do: 1. No change: Continue to accept unknown zone names. Doing otherwise will likely break parsing of times found in email headers. The rationale behind accepting and returning a time with partial information still applies. Expand the doc for Parse to point out this case explicitly. 2. Change: Accept January PDT in California and interpret it as PDT, not as an unknown zone, just as we accept February 30. |
This issue was closed by revision 1d9f67d. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by webuser1200:
The text was updated successfully, but these errors were encountered: