Because Erlang runs in a VM, and that VM provides certain useful guarantees that may or may not be provided by the underlying OS. Per the original announcement

Because Erlang runs in a VM, and that VM provides certain useful guarantees that may or may not be provided by the underlying OS. Per the original announcement about the r18 release - If time correction is enabled, the Erlang runtime system will make use of both OS system time and OS monotonic time, in order to make adjustments of the frequency of the Erlang monotonic clock. You can check if your system has support for OS monotonic time by calling erlang:system_info(os_monotonic_time_source), and you can check if time correction is enabled on your system by calling erlang:system_info(time_correction). But that's not always enough, it isn't always available, and it's not always what you want, either. Per the end of the OP (and also the official release) - To find system time: erlang:system_time/0-1 To measure time differences: call erlang:monotonic_time/0-1 twice and subtract them To define an absolute order between events on a node: erlang:unique_integer([monotonic]) Measure time and make sure an absolute order is defined: {erlang:monotonic_time(), erlang:unique_integer([monotonic])} Create a unique name: erlang:unique_integer([positive]). Couple it with a node name if you want the value to be unique in a cluster, or try using UUIDv1