Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
time: fix for "AddDate() should use UTC if loc is nil" does not seem to actually fix the issue #23048
The fix for issue #15852 time: AddDate() should use UTC if loc is nil does not seem to actually fix things. See the following snipped in golang play:
Supposedly this was fixed in https://go-review.googlesource.com/c/go/+/23561
@tve, what's the problem?
You added 0 years, 0 months, and 0 days to t1 and got the same time.
As far as our API promises, we did exactly what you asked.
Discussing internal state is out of scope, unless it impacts the package's ability to deliver on its documented API. And it's not even clear what internal state you want to see, since you deleted the issue template which asks that question.
Hmmm, two answers:
What text in either that code review or that bug makes you think this is about changing the internal values? As I read it, that bug was about making a nil Location mean the same thing as UTC, and not crashing on a nil pointer dereference.
Sorry, but yes. This is just one of the traps of DeepEqual, and is why we're increasingly moving towards using https://github.com/google/go-cmp instead.