Menu
the erlang documentation says:
erlang:now()
[...] It is also guaranteed that subsequent calls to this BIF returns continuously increasing values. Hence, the return value from now() can be used to generate unique time-stamps, and if it is called in a tight loop on a fast machine the time of the node can become skewed. [...]
I find this a little strange (especially considering that the granularity is microsecond). Why was it specced this way?
469
The runtime system works towards aligning the two system times. Depending on the time warp mode used, this can be achieved by letting Erlang system time perform a time warp. A monotonically increasing time provided by the Erlang runtime system. Erlang monotonic time increases since some unspecified point in time.
If OS system time leaps backwards, Erlang monotonic time stops briefly, but it does not freeze for extended periods of time. This as the time offset is changed to align Erlang system time with OS system time. To use this mode, ensure that all Erlang code that will execute on the runtime system is time warp safe.
When Erlang system time does a time warp backwards, the values returned from erlang:now/0 freeze (if you disregard the microsecond increments made because of the actual call) until OS system time reaches the point of the last value returned by erlang:now/0. This freeze can continue for a long time.
To be backward compatible, erlang:now/0 remains "as is", but you are strongly discouraged from using it. Many use cases of erlang:now/0 prevents you from using the new multi-time warp mode, which is an important part of this new time functionality improvement.
Because it can then be used to uniquely generate timestamp numbers. The os module has a variant which does not do that.
55
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
