Hacker News Reader

Comment by rubiquity | Hacker News Reader

For some context: the recent outages caused by the leap second were due to programming languages (most notably Go) not offering APIs to work with time separately from system time.

This link from 2014 is about Erlang's monotonic time function and about when to use the various time functions offered by the Erlang standard library. The title has "Postscript" in it because it was a chapter added to the end of the Learn You Some Erlang book because these additions were so important (as we've all learned recently).

View on HN

> the recent outages caused by the leap second were due to programming languages (most notably Go) not offering APIs to work with time separately from system time

You are misguided to blame languages or standard libraries for leap second outages: at worst they are to blame for not educating programmers about nonmonotonicity of system time on certain operating systems, depending on configuration and behaviour of their time synchronization client, if available and enabled. Support for various monotonic clocks (each good for some but not all uses of monotonic time) is not consistent across operating systems, and almost no standard library expose any of them, as they should not before third party libraries with this functionality gain widespread use.

Many languages get support for monotonic clocks in their standard lib with support on various OS.

- In C, clock_gettime() (POSIX.1-2001)

- In C++11, chrono::steady_clock()

- In Python, time.monotonic()

- In Ruby, Process.clock_gettime()

- In Erlang, see OP

- In Java, you have System.nanoTime()

IMO, all languages should follow this trend as it is an essential component for many stuff. Those are not just for leap seconds, but the system clock can go backward due to a user action.

In the case of Go, the problem has been advertised since some time (Go started to internally use a monotonic clock in Go 1.3) but is/was just ignored because it is/was deemed unimportant.

> IMO, all languages should follow this trend as it is an essential component for many stuff.

On the one hand, using different kinds of clock (clock_realtime and clock_monotonic) for different purposes currently is the only robust option when deploying on systems you do not control. On the other hand, using just one monotonic wall clock [1] for all purposes on a properly configured system is so much simpler and intuitive for programmers that it is difficult to justify the burden of multiple clocks, all the more so its necessity.

Thanks for the list!

[1] https://developers.google.com/time/smear

> You are misguided to blame languages or standard libraries

Well, Go doesn't have any monotonic clock, sooo... not so misguided in this instance.

Reply on news.ycombinator.com