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: geographical time zone names and Daylight saving time (DST) #3385

Closed
zephyr opened this issue Mar 24, 2012 · 6 comments

Comments

Projects
None yet
4 participants
@zephyr
Copy link

commented Mar 24, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2012

Comment 1:

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

Status changed to Accepted.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 3:

Labels changed: added go1.1maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2012

Comment 4:

Labels changed: removed go1.1maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2012

Comment 5:

Labels changed: added size-l.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 3, 2013

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.

@zephyr zephyr added wontfix labels Feb 3, 2013

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@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.
You can’t perform that action at this time.