time: Altered time.Time state from calling IsDST or Zone #50559
Labels
Comments
|
What is the bug here? The // 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. |
|
The location ( Closing as working as intended. |
|
Thanks for the explanation and the documentation is quite clear. Just rather odd behavior. Calling func init() {
_ = time.Unix(0, 0).IsDST()
} |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Observing bizarre state mutations around the location in an instance of
time.Time. By callingIsDST(which should be read-only, right?), the state of an instance is changed. Subsequent instances instantiated after the call toIsDSThave an updated location and altered state.https://go.dev/play/p/bq0qA7JMJIz
With output as follows:
Showing that the hash of the instance changes after calling
IsDST(Zoneproduces the same results). The hash of a new instance created after the call toIsDSTon the first instance equals the new hash.What did you expect to see?
A consistent hash and unaltered state when calling a seemingly read-only function.
What did you see instead?
A mysteriously changing hash value.
The text was updated successfully, but these errors were encountered: