This behavior is observed downstream SlyMarbo/rss#33

@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?

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?

@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).

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.

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.