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: clarify docs about standard time #4364

Closed
gopherbot opened this issue Nov 8, 2012 · 7 comments
Closed

time: clarify docs about standard time #4364

gopherbot opened this issue Nov 8, 2012 · 7 comments
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Milestone

Comments

@gopherbot
Copy link

by agm@google.com:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Try to make sense of the time.Format (for time.Parse) documentation.
2.
3.

What is the expected output?

Documentation states that the time formats are for a specific time. That is:

   Mon Jan 2 15:04:05 MST 2006
   which is Unix time 1136243045

However, this disagrees with the GNU date tool:

   $ date --date="Mon Jan 2 15:04:05 MST 2006" +%s
   1136239445

A difference of an hour (1136239445 - 1136243045 = -3600).

I was trying to use a "UTC" format "YYYY-MM-DD HH:mm:dd", and
thought (based on this documentation) that I should supply the date string for the
canonical time (in UTC). It wasn't clear based on this discrepancy whether that time was:

   "2006-01-02 22:04:05" (1136239445)

or

   "2006-01-02 23:04:05" (1136243045)

It turns out, the format I need is:

   "2006-01-02 15:04:05"

which seems to pretty much ignore the canonical time... I feel the documentation could
be more clear here. Thanks.

Which compiler are you using (5g, 6g, 8g, gccgo)?

Documentation from the golang website.

Which operating system are you using?

Linux

Which version are you using?  (run 'go version')


Please provide any additional information below.
@rsc
Copy link
Contributor

rsc commented Nov 8, 2012

Comment 2:

I think there are two separate issues here, both documentation nits.
1. The standard Unix seconds time given might be wrong (not 15:04:05 MST).
I thought maybe the output of gnu date might be because you were using a machine in
California, but I tried it on a machine in New York and got the same number you did -
1136239445 - and not the one in our docs. It is possible that gnu date is wrong but
equally possible we changed the standard time from PST to MST without updating the Unix
seconds.
2. The docs could be clearer that even if you're formatting a UTC time you still use
15:04:05 and not whatever that is in UTC.

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

Owner changed to @robpike.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 3:

Labels changed: added size-m.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 4:

Labels changed: added suggested.

@cespare
Copy link
Contributor

cespare commented Jan 7, 2013

Comment 5:

Ruby corroborates GNU date:
> Time.new(2006, 1, 2, 15, 4, 5, "-07:00").to_i
1136239445

@rsc
Copy link
Contributor

rsc commented Jan 7, 2013

Comment 6:

Sounds good. Please fix the docs then.

@cespare
Copy link
Contributor

cespare commented Jan 7, 2013

Comment 7:

See https://golang.org/cl/7069046.

@rsc
Copy link
Contributor

rsc commented Jan 22, 2013

Comment 8:

This issue was closed by revision 657168f.

Status changed to Fixed.

@gopherbot gopherbot added fixed Suggested Issues that may be good for new contributors looking for work to do. labels Jan 22, 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
@rsc rsc unassigned robpike Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Projects
None yet
Development

No branches or pull requests

4 participants