time: geographical time zone names and Daylight saving time (DST)

[zephyr]

The function `time.Parse(alayout, avalue string)` already accepts numerical (`-0700`,
`+07:00`, …) and ‘named’ (`EST`, `CET`, …) time zones, but it should also accept
geographical ones like `Europe/Berlin` or `America/New_York` as specified by the
[https://en.wikipedia.org/wiki/Tz_database tz database]. Right now, it doesn’t:
{{{
parsing time "23.03.2012 22:14 Europe/Berlin" as "02.01.2006 15:04
MST": cannot parse "Europe/Berlin" as "MST"
}}}

This is important because in some parts of the world (like the USA or Europe) rules for
[https://en.wikipedia.org/wiki/Daylight_saving_time Daylight saving time (DST)] are in
force, but most people does’t care to write down timezones because they only
‘think’ in local time. This is why the tz database works with geographical time zone
names – it delivers the programmer from DSR stuff:

`2012-03-23T22:14 Europe/Berlin` should evaluate into `+01:00` (CET/Winter time), but

`2012-06-23T15:00 Europe/Berlin` should evaluate into `+02:00` (CEST/Summer time)


This file `time-dst.go` illustrates the problem:
{{{
package main

import (
    "fmt"
    "time"
)

func main() {
    
    // working:
    mytime("23.03.2012 22:14 CET")
    mytime("23.06.2012 15:00 CEST")
    
    // failing:
    mytime("23.03.2012 22:14 Europe/Berlin")
    mytime("23.06.2012 15:00 Europe/Berlin")
    
}

func mytime(s string) {
    var format = "02.01.2006 15:04 MST" // Reference: Mon Jan 2 15:04:05 MST 2006 (MST is GMT-0700)
    
    var d, err = time.Parse(format, s)
    if err == nil {
        fmt.Println(d.Format(time.RFC3339))
    } else {
        fmt.Println(err)
    }
    fmt.Println()
}
}}}

Finally, i’m using the `6g` compiler (c1702f36df03 (release-branch.r60)
release/release.r60.3) in a Debian based GNU/Linux distribution who must not be named ;).

Attachments:

1. time-dst.go (502 bytes)

[robpike]

Comment 1:

Labels changed: added priority-later, packagechange, removed priority-triage.

Status changed to Accepted.

[robpike]

Comment 2:

See also issue #4001. I've marked this for Go 1.1 because that may be a good time to
address it along with 4001.

Labels changed: added go1.1.

[rsc]

Comment 3:

Labels changed: added go1.1maybe.

[rsc]

Comment 4:

Labels changed: removed go1.1maybe.

[rsc]

Comment 5:

Labels changed: added size-l.

[rsc]

Comment 6:

I don't believe we should accept TZ location names in the Parse patterns. Parse does not
today require file system access (except that the package loads the default TZ from disk
at startup), and I don't think we should change that precedent. There is also a question
about whether to accept both "America/New York" and "America/New_York" and, if so, which
to use when printing and how to know when the zone name is done for the purpose of a
lookup.
That said, I do intend to add a time.ParseInLocation (issue #3653), and that could be
used to build a custom parser that accepted the format you gave:
2012-03-23T22:14 Europe/Berlin
2013-02-03T15:35 America/New York
The parsing function (not time.Parse but your own) would have to deal with cutting the
time zone off (perhaps splitting at the last space before the slash), converting it into
a file path for LoadLocation (turning the space into an underscore), calling
time.LoadLocation (perhaps with a cache), and calling time.ParseInLocation.
So what you've described will be possible in Go 1.1 (it isn't today), but it won't be
there out of the box. There are too many design decisions I don't want to hard code.
Star issue #3653 for updates on ParseInLocation.

Status changed to WontFix.