sss
01/01/2017, 7:47 PM>On Mon, Oct 12, 2015 at 9:07 PM, Andrew Gerrand wrote:
>I suppose what I'm getting at is this: If there's a broad need for such a package, why isn't there one that people are already using?
Because people incorrectly assume that time only moves forward? It's an extremely common mistake that even at Google we were trying to hammer in people's head. When you see the large impact that things such as leap seconds have (including at Google), it's easy to see this is a well known problem but also a recurring problem.
How is it that a language geared towards systems programming that comes with such a rich standard library offers no standard way of measuring time correctly?
Look at gRPC, every single use of time.Now() there is buggy because it implicitly assumes that time only moves forward and at a constant pace, neither of which is true for CLOCK_REALTIME. Pretty much any distributed systems code that uses time.Now() other than for printing the current time is subtly buggy. And there is a lot of it. And it's there chiefly because there is no alternative in the standard library to get monotonic time so people don't even think about it.