time: Parse

[gopherbot]

by webuser1200:

// You can edit this code!
// Click here and start typing.
package main

import (
  "time"
)


func main() {
    splitDate, _ := time.Parse("20060102MST", "20110122EDT")
    ns := splitDate.UnixNano()
    println(ns)
}


which gives 1295654400000000000

but when I go to http://www.epochconverter.com/ and put in the time 1295654400, I get
"Fri Jan 21 2011 19:00:00 GMT-5" which is not correct 
I was expecting "Fri Jan 22 2011 00:00:00 GMT-5" which is what is passed into
time.Parse

[gopherbot]

Comment 1 by webuser1200:

splitDate, err := time.Parse("20060102MST", "20110122EDT")
fmt.Println(err)
err is nil

[robpike]

Comment 2:

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.

[rsc]

Comment 3:

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.

[remyoudompheng]

Comment 4:

I think issue #3385 and issue #3604 are quite similar. There is certainly a possible merge
between them.

[robpike]

Comment 5:

I think they're distinct issue and should be kept separate, but perhaps should all be
thought about for go1.1. I've marked them as such and cross-connected them.

[gopherbot]

Comment 6 by vinjvinj:

Is there any way to pass in America/New_York instead of EDT to get ride of any ambiguity
with EDT

[gopherbot]

Comment 7 by webuser1200:

Is there any way to pass in America/New_York instead of EDT to get ride of any ambiguity
with EDT

[rsc]

Comment 8:

Labels changed: added go1.1maybe.

[rsc]

Comment 9:

Labels changed: removed go1.1maybe.

[rsc]

Comment 10:

Labels changed: added size-l.

[rsc]

Comment 11:

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.

[rsc]

Comment 12:

This issue was closed by revision 1d9f67d.

Status changed to Fixed.