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: allows signs for year/tz in format string #11128

dvyukov opened this issue Jun 9, 2015 · 2 comments

time: allows signs for year/tz in format string #11128

dvyukov opened this issue Jun 9, 2015 · 2 comments


Copy link

@dvyukov dvyukov commented Jun 9, 2015

The following program prints 1994-01-01 00:00:00 -0059 -0059:

package main

import (

func main() {
    ret, err := time.Parse("06Z070000", "-6+-1+1-1")
    if err != nil {
    fmt.Printf("%v\n", ret)

Most of the RFCs does not allow that.

@ianlancetaylor ianlancetaylor added this to the Go1.5Maybe milestone Jun 9, 2015
Copy link

@jeffallen jeffallen commented Jun 23, 2015

I investigated this but found it difficult to decide what to do about it. Half the timezones on the planet are negative. Some timezones are off from their neighbors by 30 minutes, though none are -59 minutes, but that's not a bug, just an unused feature. So for TZ there's nothing to do. For year, it would be possible to return an error when a negative year is parsed. But what error is this saving users of the stdlib from? I find it to be a borderline case, and I'm leaning towards "works as intended".

Copy link
Member Author

@dvyukov dvyukov commented Jun 23, 2015

For some format strings time package claims to parse dates according to some RFCs. I am sure there are cases where RFCs do not permit signs, but time package does.

Also for timezone -160 I propose to not create Location with offset=0 at all (just leave it as nil). This preserves Time object unchanged after serialization/deserialization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants