3 ms·

I think that should be fine. t1.Add(diff).Equal(t2) would still hold, because Now gets monontonic time, Add and Sub maintain it, and Equal checks it.

by dilap 10y ago

Groxx 10y ago
It's entirely possible I'm wrong since I didn't read through things in great detail, but this is what I'm thinking. // time = [wall, mono], just ints for simplicity t1 = time.Now() = [10, 10] t2 = time.Now() = [19, 20] // wall clock lags slightly on second measure diff = t2.Sub(t1) = (20 - 10) == 10 // Sub only operates on mono-time t1.Add(diff) == [20, 20] // Add adds `diff` to both wall and mono [20, 20] ==?== [19, 20] I'd expect those to be different, since they represent different wall-clock times.
- dilap 10y ago
  If both times have mono time, then Equal() compares that, and ignores wall time. So t2.Equal(t1) is true. You are right that "t1 == t2" (comparing the raw bytes of the time structures) is false, but that was already broken anyway (because time-zones break raw byte equality). (Whether you think it's OK to have a language that doesn't overload == and makes you know that for complex structures you've got to call a method like Equal() probably correlates pretty highly with your opinion of Go.) There will of course be other weird things, like: print(t1) // "20 [20]" print(t2) // "19 [20]" But you could argue that's basically the least-surprising possible result in the face of the surprising fact time having gone backwards one second. :) By the way, worth mentioning that while this is all implemented in HEAD in Go, it's not a done deal yet -- it'll have a 3-month window for people to try it out in the real world, and if it's found to be problematic, it'll get backed out before becoming part of the official release.
  - Groxx 10y ago
    >If both times have mono time, then Equal() compares that, and ignores wall time. Gotcha, I missed that somewhere. That's essentially fine - then the only real surprises are when you deserialize a Time (so it doesn't have a mono time), which should in principle have no interactions with this proposal. And yeah, Equal vs ==, the meaning was clear enough that I didn't bother to be specific :) Thanks for the infos!
    - dilap 10y ago
      Cheers!

I think that should be fine. t1.Add(diff).Equal(t2) would still hold, because Now gets monontonic time, Add and Sub maintain it, and Equal checks it.

by dilap 10y ago

I think that should be fine. t1.Add(diff).Equal(t2) would still hold, because Now gets monontonic time, Add and Sub maintain it, and Equal checks it.

Groxx 10y ago

It's entirely possible I'm wrong since I didn't read through things in great detail, but this is what I'm thinking. // time = [wall, mono], just ints for simplicity t1 = time.Now() = [10, 10] t2 = time.Now() = [19, 20] // wall clock lags slightly on second measure diff = t2.Sub(t1) = (20 - 10) == 10 // Sub only operates on mono-time t1.Add(diff) == [20, 20] // Add adds `diff` to both wall and mono [20, 20] ==?== [19, 20] I'd expect those to be different, since they represent different wall-clock times.

dilap 10y ago
If both times have mono time, then Equal() compares that, and ignores wall time. So t2.Equal(t1) is true. You are right that "t1 == t2" (comparing the raw bytes of the time structures) is false, but that was already broken anyway (because time-zones break raw byte equality). (Whether you think it's OK to have a language that doesn't overload == and makes you know that for complex structures you've got to call a method like Equal() probably correlates pretty highly with your opinion of Go.) There will of course be other weird things, like: print(t1) // "20 [20]" print(t2) // "19 [20]" But you could argue that's basically the least-surprising possible result in the face of the surprising fact time having gone backwards one second. :) By the way, worth mentioning that while this is all implemented in HEAD in Go, it's not a done deal yet -- it'll have a 3-month window for people to try it out in the real world, and if it's found to be problematic, it'll get backed out before becoming part of the official release.
- Groxx 10y ago
  >If both times have mono time, then Equal() compares that, and ignores wall time. Gotcha, I missed that somewhere. That's essentially fine - then the only real surprises are when you deserialize a Time (so it doesn't have a mono time), which should in principle have no interactions with this proposal. And yeah, Equal vs ==, the meaning was clear enough that I didn't bother to be specific :) Thanks for the infos!
  - dilap 10y ago
    Cheers!