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: behavior of time compare result not same #26564

isayme opened this issue Jul 24, 2018 · 2 comments


None yet
3 participants
Copy link

commented Jul 24, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?


Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

linux amd64

What did you do?


What did you expect to see?

with different(UTC) timezone, t1 == t2 return same true.

What did you see instead?

t1 == t2 return false when timezone is UTC.


This comment has been minimized.

Copy link

commented Jul 24, 2018

You can not override == operation in golang.
So with different(UTC) timezone, t1 == t2 return same true. can not be implemented only with golang code.
Please see the document:

Struct values are comparable if all their fields are comparable. Two struct values are equal if their corresponding non-blank fields are equal.

time.Time is a struct. So it will follow the rule. So t1 == t2 return false when timezone is UTC. because the loc field is not the same.


This comment has been minimized.

Copy link

commented Jul 24, 2018

Please use time.Equal

Note that the Go == operator compares not just the time instant but also the Location and the monotonic clock reading. Therefore, Time values should not be used as map or database keys without first guaranteeing that the identical Location has been set for all values, which can be achieved through use of the UTC or Local method, and that the monotonic clock reading has been stripped by setting t = t.Round(0). In general, prefer t.Equal(u) to t == u, since t.Equal uses the most accurate comparison available and correctly handles the case when only one of its arguments has a monotonic clock reading.

Closing since this is working as documented.

@agnivade agnivade closed this Jul 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.