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.

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.

I happened across this article recently - the linked section digs into which flavors of time you might want for various applications:

That seems to make sense, but if that’s the case then what is the point of system time and time warps existing at all?

Quoting the erlang docs again:

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.

And

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.

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?