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: local timezone affects parsing RFC1123 #16517

Closed
homingli opened this issue Jul 27, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@homingli
Copy link

commented Jul 27, 2016

  1. What version of Go are you using (go version)?
    go version go1.5.3 linux/amd64
  2. What operating system and processor architecture are you using (go env)?
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
  3. What did you do?
    Parsing RFC1123 the 4digit timezone exhibit different behavior depending on local timezone.
    On my laptop set to PDT, the result is expected.
    On a server set to UTC, the result is +0000 PDT (same behavior as https://play.golang.org/p/Tlbt2g24Fb)
  4. What did you expect to see?
    2016-07-26 03:34:46 -0700 PDT
  5. What did you see instead?
    2016-07-26 03:34:46 +0000 PDT
@homingli

This comment has been minimized.

Copy link
Author

commented Jul 27, 2016

This behavior is observed downstream SlyMarbo/rss#33

@minux

This comment has been minimized.

Copy link
Member

commented Jul 27, 2016

@minux minux closed this Jul 27, 2016

@homingli

This comment has been minimized.

Copy link
Author

commented Jul 27, 2016

@minux can you explain this behavior further?

I also tried time.ParseInLocation with time.LoadLocation("Americas/Los Angeles") but still with the same behavior. How do I properly parse that time string to get the expected result consistently?

@minux

This comment has been minimized.

Copy link
Member

commented Jul 27, 2016

@homingli

This comment has been minimized.

Copy link
Author

commented Jul 29, 2016

Duh! Bad typos in my location, it's working fine. Thanks!

I still don't understand your statement though: "timezone abbreviation is only meaningful within a certain location."

Shouldn't PDT be -0700 parsed from anywhere and everywhere? If i parse PDT from Los_Angeles, or parse PDT from New_York, PDT should still mean -0700, is that not true?

@cespare

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2016

@homingli no, the abbreviations are not unique and depend on the locale. For instance if you look at this list, you can see many duplicate abbreviations (ACT, BST, etc).

@homingli

This comment has been minimized.

Copy link
Author

commented Jul 29, 2016

Wow. Did not know that timezone abbreviation is not standardized. Thanks!

Is it because PDT is not known so it parses to "+0000 PDT"? This really threw me off for some time calculations.

I'm also curious if it makes sense to have sane defaults, at least for non-duplicating definitions. But anyway, you guys are right, this is working as expected. Thank you for pointing this out to me.

@cespare

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2016

Is it because PDT is not known so it parses to "+0000 PDT"?

Yes. The docs for https://golang.org/pkg/time/#Parse say, in part:

When parsing a time with a zone abbreviation like MST, if the zone abbreviation has a defined offset in the current location, then that offset is used. The zone abbreviation "UTC" is recognized as UTC regardless of location. If the zone abbreviation is unknown, Parse records the time as being in a fabricated location with the given zone abbreviation and a zero offset.

I think that answers your question.

But if you want to discuss further, you should use the mailing list rather than this issue.

@golang golang locked and limited conversation to collaborators Jul 29, 2017

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.