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.

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

Closed
gopherbot opened this issue Aug 24, 2012 · 12 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

commented Aug 24, 2012

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

This comment has been minimized.

Copy link
Author

commented Aug 24, 2012

Comment 1 by webuser1200:

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

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2012

Comment 4:

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

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2012

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

This comment has been minimized.

Copy link
Author

commented Aug 26, 2012

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

This comment has been minimized.

Copy link
Author

commented Aug 26, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 8:

Labels changed: added go1.1maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2012

Comment 9:

Labels changed: removed go1.1maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2012

Comment 10:

Labels changed: added size-l.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2013

Comment 12:

This issue was closed by revision 1d9f67d.

Status changed to Fixed.

@gopherbot gopherbot added fixed labels Feb 4, 2013

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.