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.
