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: parser does not support IANA location names #5202

alexandre-normand opened this issue Apr 4, 2013 · 6 comments

time: parser does not support IANA location names #5202

alexandre-normand opened this issue Apr 4, 2013 · 6 comments


Copy link

@alexandre-normand alexandre-normand commented Apr 4, 2013

I started using the time package ( and it supports timezones
only in the form of timezone offsets or the "deprecated" timezone

Since abbreviations are not guaranteed to be unique, it is generally understood that
timezone names are the way to go (i.e. America/Los_Angeles instead of PST) but it's not
possible with the current time package. 

Can the support be added to the time package for zone names?
Copy link

@pjweinb pjweinb commented May 2, 2013

Comment 1:

More details please?  On my Linux and on my OSX this code prints
tz=America/Los_Angeles, err=<nil>
import (
func main() {
    a, err := time.LoadLocation("America/Los_Angeles")
    fmt.Printf("tz=%v, err=%v\n", a, err)
Copy link
Contributor Author

@alexandre-normand alexandre-normand commented May 3, 2013

Comment 2:

Sorry about the lack of context. I realize now that what I wanted is not that actually
that common. 
What I meant was that this isn't supported currently:
time.Parse("2006-01-02 15:04:05 America/Phoenix", "2006-01-02 14:04:05
My reference is joda-time where 'Z' can be used to parse a timezone id
( On
one hand, full timezone ids are safer than 3 letter codes because they are unique and
include DST info but on the other hand, systems that format date/time in such a way are
indeed rare. 
I guess the question comes down to focusing the support on the more common cases out
there or trying to pave the way for better time handling. Does that make sense?
Copy link

@rsc rsc commented Jun 3, 2013

Comment 3:

I'd really like to avoid calling LoadLocation (and therefore doing file I/O) from the

Status changed to Thinking.

Copy link

@gopherbot gopherbot commented Jun 3, 2013

Comment 4 by

It's fair. My  aggravation actually faded somewhat after seeing how not very common this
is. I'd just like timezone handling to be perfect everywhere so that we all would be
happy and smiling when it comes time to deal with human readable time.  
Sadly, the state of time handling is universally still cringe-worthy,
approximation-filled and overall, a very fragile thing. 
td;lr: It's a desirable feature but considering how uncommon it is that times are
formatted to preserve all information, this might be reasonable to make compromises.
Copy link

@gopherbot gopherbot commented Jun 4, 2013

Comment 5 by

Adding to my previous, not very constructive comment, I'd like to mention a few things
that, although not specific to Go, might be considered regarding this feature.
Unless I'm missing something, dealing with date time values can be done a few different
ways and only one of them is fully lossless:
 * Date/Time with 3 letters abbreviations: 2006-01-02 15:04:05 PDT (this seems reasonable but there are known conflicts which invalidate this approach unless you're dealing with users on specific markets only). See and look for duplicates, like MST.
 * Date/Time with a generic timezone offset: 2006-01-02 15:04:05 -07:00. This is not ambiguous but it doesn't preserve the daylight savings settings of where the date comes from, losing the user's timezone information. It does, however, accurately represent a moment in time and it might be fine if an application knows the user's location and deals appropriately with this.
* Date/Time with the timezone id:   2006-01-02 14:04:05 America/Los_Angeles. This is not
ambiguous and it also provides all the timezone and daylight savings info one could
need. Downside? No system actually formats dates this way and there's therefore a
problem of integrating with other systems that already lost information.
To me, the time offsets + separate location handling is probably the most sensible
approach in the current state of everything™ but it would still be nice to allow for a
better way if people can ever have a chance of dealing more easily and reliably with
date/time parsing/formatting.
Copy link

@rsc rsc commented Jun 10, 2013

Comment 6:

I don't think there's anything to do here, sorry.
It's possible to build a parser expecting IANA names (or IANA names with spaces instead
of underscores) from the pieces provided.

Status changed to Unfortunate.

@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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.