3 ms·

> 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 ti

by orivej 10y ago

> 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.

vbernat 10y ago
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.
- orivej 10y ago
  > 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 https://developers.google.com/time/smear
dom0 10y ago
> You are misguided to blame languages or standard libraries Well, Go doesn't have any monotonic clock, sooo... not so misguided in this instance.

by orivej 10y ago

vbernat 10y ago

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.

orivej 10y ago
> 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 https://developers.google.com/time/smear

dom0 10y ago

> You are misguided to blame languages or standard libraries Well, Go doesn't have any monotonic clock, sooo... not so misguided in this instance.