time: Parse behaves inconsistently when parsing numerical timezones with an "MST" format string #30780
Comments
This looks like a bug to me,
|
/cc @ianlancetaylor |
Currently, an "MST" value in the Parse layout string corresponds to a stdTZ token. "-0000" parses successfully, but "-0700" does not. These are both stdNumTZ values, and neither should parse as stdTZ. Fixes golang#30780
Change https://golang.org/cl/167381 mentions this issue: |
This expectation is not correct. Not every timezone has a three-letter name, so it was decided to allow numeric timezone names (like |
Yes, timezones of |
But how do you differentiate between a numeric timezone name and an |
In the A value of This behavior is already part of |
My point is that this is wrong. It's also the current behaviour, but now your CL is aligning Parse, for |
They are valid numeric timezone names, but not valid non-numeric timezone names. If you use Are you suggesting that they should be interchangeable? Because that also solves this bug, but seems to me to be non-obvious behavior. My initial reaction is that I would be surprised if I was able to hand a non-numeric timezone designator to a function that uses a layout string specifying a 4-digit offset. Otherwise, why recognize a difference between these two types in the layout string? |
Here's how I understand it:
This is how I read the documentation, where it says:
so no, I don't think they are interchangeable, since with |
Ah, I understand where you're coming from. That would be a fine solution as well, as long as behavior is consistent when parsing strings that are suffixed with both |
/cc @robpike // parseSignedOffset parses a signed timezone offset (e.g. "+03" or "-04"). This function is expecting "+03" and accepting "-0000" (unexpectedly!) but rejecting "-0700" (because 700 is well out of range). It's unclear what the right answer is - should parseSignedOffset allow 4-digit offsets in order to deal with fractional-hour time zones? |
This will be necessary anyway to fix #26032. For example, if you zdump
which |
What are the next steps required for this? |
@nickmooney We need to decide on the right thing to do. |
Gotcha, @ianlancetaylor. I haven't contributed to Go before, and I'm not super familiar with who is in charge of making those decisions. It seems like we have two options -- is there a group of people who are the "right people" to make that decision? |
Yes, there is a group of people who periodically review In this case it would be interesting to hear whether @robpike has an opinion. |
Perhaps parseSignedOffset should allow 4-digit offsets. I'm not sure. |
What version of Go are you using (
go version
)?Local machine:
Docker container:
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Go Playground example here.
I attempted to use the
time.Parse
format string"Mon, 2 Jan 2006 15:04:05 MST"
to parse the date"Tue, 12 Mar 2019 15:34:39 -0000"
.What did you expect to see?
I would expect
time.Parse
to fail to parse the string, since it's suffixed with-0000
rather than an alphabetical time zone designator.This behaves correctly when I try to parse a date with a non-zero offset, such as
"Tue, 12 Mar 2019 15:34:39 -0700"
(i.e. parsing fails).What did you see instead?
time.Parse
successfully parses date strings with TZ offsets of zero given a format string that ends withMST
, when it should likely fail if there is no alphabetical timezone designator.The text was updated successfully, but these errors were encountered: