Comment 1:

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

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
America/Los_Angeles") 
My reference is joda-time where 'Z' can be used to parse a timezone id
(http://joda-time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html). 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?

Comment 3:

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

Status changed to Thinking.

Comment 4 by alexandre.normand@opower.com:

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.

Comment 5 by alexandre.normand@opower.com:

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 http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations 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.

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.