There is some mention of the differences in the docs for system_time/0:
It is the VM view of the os_time/0. They may not match in
case of time warps although the VM works towards aligning
them. This time is not monotonic.
Likewise, the Erlang docs also discuss some implications:
OS System Time
The operating systems view of POSIX time. To retrieve it, call os:system_time(). This may or may not be an accurate view of POSIX time. This time may typically be adjusted both backwards and forwards without limitation. That is, time warps may be observed.
This time may or may not be an accurate view of POSIX time, and may or may not align with OS system time. 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.
However, besides the talk of time warps and what exactly each of the functions return, there is never really any advice about when you would want one or the other.
Thanks for the link, super interesting. It covers the difference between monotonic and wall time well, but it doesnât really cover OS Time vs System Time. The erlang docs seem to suggest that for getting the wall time, System Time should be the default, however, DateTime in Elixir uses OS Time. I wonder if thereâs a reason for that?
I would say OS time is correct. For an embedded device Or desktop application, if the os time changes, then it should be immediately reflected in the app. The same for log timestamps and so on. For servers I may not Matter anyway as they are usually in UTC and do not observe jumps.
The number of problems that arise when you always expect the wall clock time on the system to be correct can be immense. Erlang therefore introduced the âcorrected estimate of timeâ, or the âtime correctionâ, many years ago.
As we align Erlang system time with OS system time by changing the time offset, we can enable a time correction that tries to adjust the frequency of the Erlang monotonic clock to be as correct as possible. This makes time measurements using Erlang monotonic time more accurate and precise.
This is saying that there are problems being solved and accuracy and precision benefits to Erlang monotonic time, but it does not mention why Erlang system time (based on Erlang monotonic time) would be preferable to OS system time.
learn you some Erlang also discusses this, but again does not make a recommendation between System and OS time.
As most servers use Network Time Protocol (NTP) the time may jump as time drifts and itâs synchronized with the external clock. Have seen this happen in production and the results werenât pretty. Scanner imports were rejected because the serversâ clock jumped backward, even when it was a small amount.
Those are the cases where system_time seems to be designed for, where âsystemâ is âErlangâ. You can tune how it behaves when such jump (or drift) happens. For instance: only allow âtimeâ to go forward, no jumps (using correction).
As a result the time you get might not immediately be the time you expect, but itâs more robust and predictable from a systemsâ perspective.
Recommendations
os_time for user observable time as it matches expectation and wall clock. Examples:
the new log entry has a timestamp matching the clock on the wall
the clock shown on the screen matches the clock on the wall
system_time for internal time(rs) & time measuring as external interference with the clock is dampened and the clock is more predictable for processes. Examples:
order events by timestamp will always match order by incremental id
processes expected to run on a strict interval will not alert due to a time jump
ps. I am not an expert
pps. There is no better way then getting the answer from an expert than posting a wrong answer. So when itâs wrong we will find out soon.
It seems like both of these cases could be handled by using monotonic time. Do you see a use for Erlang system time specifically over monotonic time here?
If youâre depending on precise time continuity and non-repudiation of time (i.e., monotonicity of time) within Erlang VM, use erlang:system_time/0-1.
Erlang monotonic time increases since some unspecified point in time
Even Erlang system time is based on Erlang monotonic time. By adding current Erlang monotonic time with current time offset, you get current Erlang system time.
To retrieve the current time offset, callerlang:time_offset/0.
When you also want to use the time other than âtime elapsedâ (eg. print or store start- and stop time of measurement) you better use system time as monotonic time has no reference to a âclock on the wallâ at all.
I just ran into a case where on my MacBook Pro, if I have an iex session running and then let my laptop sleep, when I wake my laptop in the morning, System.system_time() in the existing iex session will lag behind System.system_time() in a new iex session. As far as I can tell, the lag will remain until I restart the VM. Iâm running Erlang/OTP 25 and Elixir 1.14.3.
This problem manifested as an invalid nbf (not before) claim in an oauth token because the times were being compared with System.system_time() and not System.os_time().
Iâm still investigating to see if this behavior changed in recent versions of Erlang/OTP, since we hadnât seen this prior to a recent upgrade.
As announced when OTP 25 was released, multi time warp mode is now enabled by default. This assumes that all code executing on the system is time warp safe.
Iâm not sure of all the details, but hereâs what I learned from testing.
On Erlang/OTP 23 [erts-11.1.7] and Elixir 1.11.3, if I let my laptop sleep with an open iex session, when it woke up, System.system_time(:second) == System.os_time(:second) evaluated to true.
On Erlang/OTP 25 [erts-13.2] and Elixir 1.14.3, doing the same evaluates to false, unless I start iex with iex --erl "+C multi_time_warp" -S mix.
