
Postscript: Time Goes On (2014) - tosh
http://learnyousomeerlang.com/time
======
rubiquity
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).

~~~
orivej
> 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
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
> 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)

------
justinph
Clicked on this expecting some neat hack with the Postscript language (PDFs,
printers, etc). Instead, some stuff about time.

~~~
CharlesW
Not to be "that guy", but an article about PostScript would most likely be
CamelCase.

~~~
shitgoose
mouse click is much faster than brain signal. i also clicked to read about
postscript language.

~~~
sjwright
And another. Use of camel case isn't consistent enough to be a useful signal.
It might as well be an article about snakes beginning with "Python:".

Even the remaining text is no help. "Time goes on" could easily refer to the
fact that PostScript is a very old standard.

