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: regression in time.Parse from Go 1.11 to 1.12 #32358
Comments
I think that this is due to htps://golang.org/cl/130696 which was part of the fixes for #26032. It's not obvious to me that the new behavior is wrong. It's a change, but the resulting date does seem to match the input. Why is this wrong? |
I found this while debugging an issue in a library I didn't write. This library depends on the error behavior of But to me, |
We accept numeric-looking zone names when matching against MST because not every timezone has a three-letter abbreviation. Many timezones has an abbreviation that looks like a number. If this works:
then why it shouldn't with +00 ? And if we accept +00 we should also accept +0000, since the 4-digits format for the numeric abbreviated timezone name is used for timezones with non-integral UTC offset. |
package main
import (
"log"
"time"
)
func main() {
_, err := time.Parse(time.UnixDate, time.Now().UTC().Format(time.RubyDate))
if err == nil {
log.Fatal("no error")
}
} As it is now you have a situation where I understand the complexity of time and timezones and appreciate all the work that has been done on this. I'm just reporting a real issue found in the wild, I'm not saying it has to be fixed. |
I don't think it should. It uses
You're right, but my point is that we should accept both (not error on both); so what we do now on +0000 is correct and the fact that we reject things like +0430 is #26032, which we should fix sooner or later. So in the end I think your snippet is WAI and the inconsistency between +0000 and +0430 is #26032. |
@ALTree I understand the complexity, but I still think it's the wrong thing to mix timezone abbreviations with timezone offsets. Esp. when you see who they are treated so fundamentally different in |
Do you have a concrete suggestion on how to handle matching MST with timezones abbreviations? Suppose I have this format string:
Now I zdump the current time in Rome and Singapore:
Should the Singapore timestamp be rejected by Parse? But then we're back at square 1: the timestamp is accepted or not depending on where we are. "MST" doesn't mean "a three letter abbreviation". It just means "whatever the tzdatabase uses as a shorthand for the timezone name". If the shorthand for "Asia/Singapore" is |
For the reason outlined in #32358 (comment) I don't think this is a bug. Closing this issue. |
See https://play.golang.org/p/dADhD0_mYTH
The above runs fine on Go 1.11 (
time.Parse
returns an error), but fails in Go 1.12 and later.The text was updated successfully, but these errors were encountered: