Introduce a new time API

The old time API is based on erlang:now/0. The major issue with
erlang:now/0 is that it was intended to be used for so many
unrelated things. This tied these unrelated operations together
and unnecessarily caused performance, scalability as well as
accuracy, and precision issues for operations that do not need
to have such issues. The new API spreads different functionality
over multiple functions in order to improve on this.

The new API consists of a number of new BIFs:
- erlang:convert_time_unit/3
- erlang:monotonic_time/0
- erlang:monotonic_time/1
- erlang:system_time/0
- erlang:system_time/1
- erlang:time_offset/0
- erlang:time_offset/1
- erlang:timestamp/0
- erlang:unique_integer/0
- erlang:unique_integer/1
- os:system_time/0
- os:system_time/1

and a number of extensions of existing BIFs:
- erlang:monitor(time_offset, clock_service)
- erlang:system_flag(time_offset, finalize)
- erlang:system_info(os_monotonic_time_source)
- erlang:system_info(time_offset)
- erlang:system_info(time_warp_mode)
- erlang:system_info(time_correction)
- erlang:system_info(start_time)

See the "Time and Time Correction in Erlang" chapter of the
ERTS User's Guide for more information.

1 files changed, 672 insertions, 103 deletions

diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 483d81cfb6..3cbfd372ce 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -58,7 +58,71 @@
     </datatype>
     <datatype>
       <name name="timestamp"></name>
-      <desc><p>See <seealso marker="#now/0">now/0</seealso>.</p>
+      <desc><p>See <seealso marker="#timestamp/0">erlang:timestamp/0</seealso>.</p>
+      </desc>
+    </datatype>
+    <marker id="type_time_unit"/>
+    <datatype>
+      <name name="time_unit"></name>
+      <desc><p>Currently supported time unit representations:</p>
+        <taglist>
+	  <tag><c>PartsPerSecond :: integer() >= 1</c></tag>
+	  <item><p>Time unit expressed in parts per second. That is,
+	  the time unit equals <c>1/PartsPerSecond</c> second.</p></item>
+
+	  <tag><c>seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1</c>.</p></item>
+
+	  <tag><c>milli_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000</c>.</p></item>
+
+	  <tag><c>micro_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000000</c>.</p></item>
+
+	  <tag><c>nano_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000000000</c>.</p></item>
+
+	  <tag><c>native</c></tag>
+	  <item><p>Symbolic representation of the native time unit
+	  used by the Erlang runtime system.</p>
+
+	  <p>The <c>native</c> time unit is determined at
+	  runtime system start, and will remain the same until
+	  the runtime system terminates. If a runtime system
+	  is stopped and then started again (even on the same
+	  machine), the <c>native</c> time unit of the new
+	  runtime system instance may differ from the
+	  <c>native</c> time unit of the old runtime system
+	  instance.</p>
+
+	  <p>One can get an approximation of the <c>native</c>
+	  time unit by calling <c>erlang:convert_time_unit(1,
+	  seconds, native)</c>. The result equals the number
+	  of whole <c>native</c> time units per second. In case
+	  the number of <c>native</c> time units per second does
+	  not add up to a whole number, the result will be
+	  rounded downwards.</p>
+
+	  <note>
+	    <p>The value of the <c>native</c> time unit gives
+	    you more or less no information at all about the
+	    quality of time values. It sets an upper bound for
+	    the resolution as well as for the precision, but it
+	    gives absolutely no information at all about the
+	    accuracy.</p>
+	  </note>
+	  </item>
+
+	</taglist>
+
+	<p>The <c>time_unit/0</c> type may be extended. Use
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit/3</c></seealso>
+	in order to convert time values between time units.</p>
+
       </desc>
     </datatype>
   </datatypes>
@@ -585,6 +649,22 @@
       </desc>
     </func>
     <func>
+      <name name="convert_time_unit" arity="3"/>
+      <fsummary>Convert time unit of a time value</fsummary>
+      <desc>
+	<p>Converts the <c><anno>Time</anno></c> value of time unit
+	<c><anno>FromUnit</anno></c> to the corresponding
+	<c><anno>ConvertedTime</anno></c> value of time unit
+	<c><anno>ToUnit</anno></c>. The result is rounded
+	using the floor function.</p>
+
+	<warning><p>You may lose accuracy and precision when converting
+	between	time units. In order to minimize such loss, collect all
+	data at <c>native</c> time unit and do the conversion on the end
+	result.</p></warning>
+      </desc>
+    </func>
+    <func>
       <name name="crc32" arity="1"/>
       <fsummary>Compute crc32 (IEEE 802.3) checksum</fsummary>
       <desc>
@@ -2191,14 +2271,15 @@ os_prompt% </pre>
     </func>
     <func>
       <name name="make_ref" arity="0"/>
-      <fsummary>Return an almost unique reference</fsummary>
+      <fsummary>Return a unique reference</fsummary>
       <desc>
-        <p>Returns an almost unique reference.</p>
-        <p>The returned reference will re-occur after approximately 2^82
-          calls; therefore it is unique enough for practical purposes.</p>
-        <pre>
-> <input>make_ref().</input>
-#Ref&lt;0.0.0.135></pre>
+	<p>Return a <seealso marker="doc/efficiency_guide:advanced#unique_references">unique
+	reference</seealso>. The reference is unique among
+	connected nodes.</p>
+	<warning><p>Known issue: When a node is restarted multiple
+	times with the same node name, references created
+	on a newer node can be mistaken for a reference
+	created on an older node with the same node name.</p></warning>
       </desc>
     </func>
     <func>
@@ -2499,97 +2580,178 @@ os_prompt% </pre>
       </desc>
     </func>
     <func>
-      <name name="monitor" arity="2"/>
+      <name name="monitor" arity="2" clause_i="1"/>
+      <name name="monitor" arity="2" clause_i="2"/>
+      <type name="registered_name"/>
+      <type name="registered_process_identifier"/>
+      <type name="monitor_process_identifier"/>
       <fsummary>Start monitoring</fsummary>
       <desc>
-        <p>The calling process starts monitoring <c><anno>Item</anno></c> which is
-          an object of type <c><anno>Type</anno></c>.</p>
-        <p>Currently only processes can be monitored, i.e. the only
-          allowed <c><anno>Type</anno></c> is <c>process</c>, but other types may be
-          allowed in the future.</p>
-        <p><c><anno>Item</anno></c> can be:</p>
-        <taglist>
-          <tag><c>pid()</c></tag>
-          <item>
-            <p>The pid of the process to monitor.</p>
-          </item>
-          <tag><c>{RegName, Node}</c></tag>
-          <item>
-            <p>A tuple consisting of a registered name of a process and
-              a node name. The process residing on the node <c>Node</c>
-              with the registered name <c>RegName</c> will be monitored.</p>
-          </item>
-          <tag><c>RegName</c></tag>
-          <item>
-            <p>The process locally registered as <c>RegName</c> will be
-              monitored.</p>
-          </item>
-        </taglist>
-        <note>
-          <p>When a process is monitored by registered name, the process
-            that has the registered name at the time when
-            <c>monitor/2</c> is called will be monitored.
+	<p>Send a monitor request of type <c><anno>Type</anno></c> to the
+	entity identified by <c><anno>Item</anno></c>. The caller of
+	<c>monitor/2</c> will later be notified by a monitor message on the
+	following format if the monitored state is changed:</p>
+        <code type="none">{Tag, <anno>MonitorRef</anno>, <anno>Type</anno>, Object, Info}</code>
+	<note><p>The monitor request is an asynchronous signal. That is, it
+	takes time before the signal reach its destination.</p></note>
+	<p>Currently valid <c><anno>Type</anno></c>s:</p>
+	<taglist>
+	  <tag><marker id="monitor_process"/><c>process</c></tag>
+	  <item>
+	    <p>Monitor the existence of the process identified by
+	    <c><anno>Item</anno></c>. Currently valid
+	    <c><anno>Item</anno></c>s in combination with the
+	    <c>process <anno>Type</anno></c>:</p>
+            <taglist>
+              <tag><c>pid()</c></tag>
+              <item>
+		<p>The process identifier of the process to monitor.</p>
+              </item>
+              <tag><c>{RegisteredName, Node}</c></tag>
+              <item>
+		<p>A tuple consisting of a registered name of a process and
+		a node name. The process residing on the node <c>Node</c>
+		with the registered name <c>{RegisteredName, Node}</c> will
+		be monitored.</p>
+              </item>
+              <tag><c>RegisteredName</c></tag>
+              <item>
+		<p>The process locally registered as <c>RegisteredName</c>
+		will become monitored.</p>
+              </item>
+            </taglist>
+            <note><p>When a process is monitored by registered name, the
+	    process that has the registered name at the time when the
+            monitor request reach its destination will be monitored.
             The monitor will not be effected, if the registered name is
-            unregistered.</p>
-        </note>
-        <p>A <c>'DOWN'</c> message will be sent to the monitoring
-          process if <c><anno>Item</anno></c> dies, if <c><anno>Item</anno></c> does not exist,
-          or if the connection is lost to the node which <c><anno>Item</anno></c>
-          resides on. A <c>'DOWN'</c> message has the following pattern:</p>
-        <code type="none">
-{'DOWN', MonitorRef, Type, Object, Info}</code>
-        <p>where <c>MonitorRef</c> and <c>Type</c> are the same as
-          described above, and:</p>
-        <taglist>
-          <tag><c>Object</c></tag>
-          <item>
-            <p>A reference to the monitored object:</p>
-            <list type="bulleted">
-              <item>the pid of the monitored process, if <c><anno>Item</anno></c> was
-               specified as a pid.</item>
-              <item><c>{RegName, Node}</c>, if <c><anno>Item</anno></c> was specified as
-              <c>{RegName, Node}</c>.</item>
-              <item><c>{RegName, Node}</c>, if <c><anno>Item</anno></c> was specified as
-              <c>RegName</c>. <c>Node</c> will in this case be the
-               name of the local node (<c>node()</c>).</item>
-            </list>
-          </item>
-          <tag><c>Info</c></tag>
-          <item>
-            <p>Either the exit reason of the process, <c>noproc</c>
-              (non-existing process), or <c>noconnection</c> (no
-              connection to <c><anno>Node</anno></c>).</p>
-          </item>
-        </taglist>
-        <note>
-          <p>If/when <c>monitor/2</c> is extended (e.g. to
-            handle other item types than <c>process</c>), other
-            possible values for <c>Object</c>, and <c>Info</c> in the
-            <c>'DOWN'</c> message will be introduced.</p>
-        </note>
-        <p>The monitoring is turned off either when the <c>'DOWN'</c>
-          message is sent, or when
-          <seealso marker="#demonitor/1">demonitor/1</seealso>
-          is called.</p>
-        <p>If an attempt is made to monitor a process on an older node
-          (where remote process monitoring is not implemented or one
-          where remote process monitoring by registered name is not
-          implemented), the call fails with <c>badarg</c>.</p>
-        <p>Making several calls to <c>monitor/2</c> for the same
-          <c><anno>Item</anno></c> is not an error; it results in as many, completely
-          independent, monitorings.</p>
+            unregistered, or unregistered and later registered on another
+	    process.</p></note>
+	    <p>The monitor is triggered either when the monitored process
+	    terminates, is non existing, or if the connection to it is
+	    lost. In the case the connection to it is lost, we do not know
+	    if it still exist or not. After this type of monitor has been
+	    triggered, the monitor is automatically removed.</p>
+            <p>When the monitor is triggered a <c>'DOWN'</c> message will
+	    be sent to the monitoring process. A <c>'DOWN'</c> message has
+	    the following pattern:</p>
+            <code type="none">{'DOWN', MonitorRef, Type, Object, Info}</code>
+            <p>where <c>MonitorRef</c> and <c>Type</c> are the same as
+            described above, and:</p>
+            <taglist>
+              <tag><c>Object</c></tag>
+              <item>
+		<p>equals:</p>
+		<taglist>
+		  <tag><c><anno>Item</anno></c></tag>
+		  <item>If <c><anno>Item</anno></c> was specified by a
+		  pid.</item>
+		  <tag><c>{RegisteredName, Node}</c></tag>
+		  <item>If <c><anno>Item</anno></c> was specified as
+		  <c>RegisteredName</c>, or <c>{RegisteredName, Node}</c>
+		  where <c>Node</c> corresponds to the node that the
+		  monitored process resides on.</item>
+		</taglist>
+              </item>
+              <tag><c>Info</c></tag>
+              <item>
+		<p>Either the exit reason of the process, <c>noproc</c>
+		(non-existing process), or <c>noconnection</c> (no
+		connection to the node where the monitored process
+		resides).</p></item>
+	    </taglist>
+	    <p>The monitoring is turned off either when the <c>'DOWN'</c>
+	    message is sent, or when
+	    <seealso marker="#demonitor/1">demonitor/1</seealso>
+	    is called.</p>
+	    <p>If an attempt is made to monitor a process on an older node
+	    (where remote process monitoring is not implemented or one
+	    where remote process monitoring by registered name is not
+	    implemented), the call fails with <c>badarg</c>.</p>
+	    <note>
+	      <p>The format of the <c>'DOWN'</c> message changed in the 5.2
+	      version of the emulator (OTP release R9B) for monitor
+	      <em>by registered name</em>. The <c>Object</c> element of
+	      the <c>'DOWN'</c> message could in earlier versions
+	      sometimes be the pid of the monitored process and sometimes
+	      be the registered name. Now the <c>Object</c> element is
+	      always a tuple consisting of the registered name and
+	      the node name. Processes on new nodes (emulator version 5.2
+	      or greater) will always get <c>'DOWN'</c> messages on
+	      the new format even if they are monitoring processes on old
+	      nodes. Processes on old nodes will always get <c>'DOWN'</c>
+	      messages on the old format.</p>
+	    </note>
+	  </item>
+	  <tag><marker id="monitor_time_offset"/><c>time_offset</c></tag>
+	  <item>
+	    <p>Monitor changes in
+	    <seealso marker="#time_offset/0">time offset</seealso>
+	    between
+	    <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	    monotonic time</seealso> and
+	    <seealso marker="time_correction#Erlang_System_Time">Erlang
+	    system time</seealso>. There is only one valid
+	    <c><anno>Item</anno></c> in combination with the
+	    <c>time_offset <anno>Type</anno></c>, namely the atom
+	    <c>clock_service</c>. Note that the atom <c>clock_service</c> is
+	    <em>not</em> the registered name of a process. In this specific
+	    case it serves as an identifier of the runtime system internal
+	    clock service at current runtime system instance.</p>
+
+	    <p>The monitor is triggered when the time offset is changed.
+	    This either if the time offset value is changed, or if the
+	    offset is changed from preliminary to final during
+	    <seealso marker="#system_flag_time_offset">finalization
+	    of the time offset</seealso> when the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso> is used. When a change from preliminary
+	    to final time offset is made, the monitor will be triggered once
+	    regardless of whether the time offset value was changed due to
+	    the finalization or not.</p>
+
+	    <p>If the runtime system is in
+	    <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso>, the time offset will be changed when
+	    the runtime system detects that the
+	    <seealso marker="time_correction#OS_System_Time">OS system
+	    time</seealso> has changed. The runtime system will, however,
+	    not detect this immediately when it happens. A task checking
+	    the time offset is scheduled to execute at least once a minute,
+	    so under normal operation this should be detected within a
+	    minute, but during heavy load it might take longer time.</p>
+
+	    <p>The monitor will <em>not</em> be automatically removed
+	    after it has been triggered. That is, repeated changes of
+	    the time offset will trigger the monitor repeatedly.</p>
+
+            <p>When the monitor is triggered a <c>'CHANGE'</c> message will
+	    be sent to the monitoring process. A <c>'CHANGE'</c> message has
+	    the following pattern:</p>
+            <code type="none">{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}</code>
+            <p>where <c>MonitorRef</c>, <c><anno>Type</anno></c>, and 
+	    <c><anno>Item</anno></c> are the same as described above, and
+	    <c>NewTimeOffset</c> is the new time offset.</p>
+
+	    <p>When the <c>'CHANGE'</c> message has been received you are
+	    guaranteed not to retrieve the old time offset when calling
+	    <seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>.
+	    Note that you may observe the change of the time offset
+	    when calling <c>erlang:time_offset()</c> before you
+	    get the <c>'CHANGE'</c> message.</p>
+
+	  </item>
+	</taglist>
+	<p>Making several calls to <c>monitor/2</c> for the same
+	<c><anno>Item</anno></c> and/or <c><anno>Type</anno></c> is not
+	an error; it results in many, completely independent,
+	monitorings.</p>
+	<p>The monitor functionality is expected to be extended. That is,
+	other <c><anno>Type</anno></c>s and <c><anno>Item</anno></c>s
+	are expected to be supported in	the future.</p>
         <note>
-          <p>The format of the <c>'DOWN'</c> message changed in the 5.2
-            version of the emulator (OTP release R9B) for monitor <em>by registered name</em>. The <c>Object</c> element of
-            the <c>'DOWN'</c> message could in earlier versions
-            sometimes be the pid of the monitored process and sometimes
-            be the registered name. Now the <c>Object</c> element is
-            always a tuple consisting of the registered name and
-            the node name. Processes on new nodes (emulator version 5.2
-            or greater) will always get <c>'DOWN'</c> messages on
-            the new format even if they are monitoring processes on old
-            nodes. Processes on old nodes will always get <c>'DOWN'</c>
-            messages on the old format.</p>
+          <p>If/when <c>monitor/2</c> is extended, other
+            possible values for <c>Tag</c>, <c>Object</c>, and
+	    <c>Info</c> in the monitor message will be introduced.</p>
         </note>
       </desc>
     </func>
@@ -2640,6 +2802,51 @@ os_prompt% </pre>
       </desc>
     </func>
     <func>
+      <name name="monotonic_time" arity="0"/>
+      <fsummary>Current Erlang monotonic time</fsummary>
+      <desc>
+	<p>Returns the current
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	monotonic time</seealso> in <c>native</c>
+	<seealso marker="#type_time_unit">time unit</seealso>. This
+	is a monotonically increasing time since some unspecified point in
+	time.</p>
+
+	<note><p>This is a
+	<seealso marker="time_correction#Monotonically_Increasing">monotonically increasing</seealso> time, but <em>not</em> a
+	<seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly monotonically increasing</seealso>
+	time. That is, consecutive calls to
+	<c>erlang:monotonic_time/0</c> may produce the same result.</p>
+
+	<p>Different runtime system instances will use different
+	unspecified points in time as base for their Erlang monotonic clocks.
+	That is, it is <em>pointless</em> comparing monotonic times from
+	different runtime system instances. Different runtime system instances
+	may also place this unspecified point in time different relative
+	runtime system start. It may be placed in the future (time at start
+	will be a negative value), the past (time at start will be a
+	positive value), or the runtime system start (time at start will
+	be zero). The monotonic time as of runtime system start can be
+	retrieved by calling
+	<seealso marker="#system_info_start_time"><c>erlang:system_info(start_time)</c></seealso>.</p></note>
+      </desc>
+    </func>
+    <func>
+      <name name="monotonic_time" arity="1"/>
+      <fsummary>Current Erlang monotonic time</fsummary>
+      <desc>
+	<p>Returns the current
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	monotonic time</seealso> converted
+	into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Same as calling
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c>,
+	native, <anno>Unit</anno>)</c>
+	however optimized for commonly used <c><anno>Unit</anno></c>s.</p>
+      </desc>
+    </func>
+    <func>
       <name name="nif_error" arity="1"/>
       <fsummary>Stop execution with a given reason</fsummary>
       <desc>
@@ -2734,6 +2941,13 @@ os_prompt% </pre>
       <type name="timestamp"/>
       <fsummary>Elapsed time since 00:00 GMT</fsummary>
       <desc>
+	<warning><p><em>This function is deprecated! Do not use it!</em>
+	See the users guide chapter
+	<seealso marker="time_correction">Time and Time Correction</seealso>
+	for more information. Specifically the 
+	<seealso marker="time_correction#Dos_and_Donts">Dos and Dont's</seealso>
+	section for information on what to use instead of <c>erlang:now/0</c>.
+	</p></warning>
         <p>Returns the tuple <c>{MegaSecs, Secs, MicroSecs}</c> which is
           the elapsed time since 00:00 GMT, January 1, 1970 (zero hour)
           on the assumption that the underlying OS supports this.
@@ -2746,10 +2960,6 @@ os_prompt% </pre>
         <p>It can only be used to check the local time of day if
           the time-zone info of the underlying operating system is
           properly configured.</p>
-        <p>If you do not need the return value to be unique and
-          monotonically increasing, use
-          <seealso marker="kernel:os#timestamp/0">os:timestamp/0</seealso>
-          instead to avoid some overhead.</p>
       </desc>
     </func>
     <func>
@@ -5496,6 +5706,35 @@ ok
         <p>Returns the old value of the flag.</p>
       </desc>
     </func>
+    <marker id="system_flag_time_offset"/>
+    <func>
+      <name name="system_flag" arity="2" clause_i="12"/>
+      <fsummary>Finalize the Time Offset</fsummary>
+      <desc>
+        <p>Finalizes the <seealso marker="#time_offset/0">time offset</seealso>
+	when the <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	time warp mode</seealso> is being used. If another time warp mode than
+	the "single time warp mode" is used, the time offset state will be left
+	unchanged.</p>
+        <p>Returns the old state identifier. That is, if:</p>
+	<list>
+	  <item><p><c>preliminary</c> is returned, finalization was
+	  performed and the time offset is now final.</p></item>
+
+	  <item><p><c>final</c> is returned, the time offset was
+	  already in the final state. This either due to another
+	  <c>erlang:system_flag(time_offset, finalize)</c> call, or
+	  due to the
+	  <seealso marker="time_correction#No_Time_Warp_Mode">no
+	  time warp mode</seealso> being used.</p></item>
+
+	  <item><p><c>volatile</c> is returned, the time offset
+	  cannot be finalized due to the 
+	  <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	  time warp mode</seealso> being used.</p></item>
+	</list>
+      </desc>
+    </func>
     <func>
       <name name="system_info" arity="1" clause_i="1"/>
       <name name="system_info" arity="1" clause_i="2"/>
@@ -5776,6 +6015,15 @@ ok
       <name name="system_info" arity="1" clause_i="53"/>
       <name name="system_info" arity="1" clause_i="54"/>
       <name name="system_info" arity="1" clause_i="55"/>
+      <name name="system_info" arity="1" clause_i="56"/>
+      <name name="system_info" arity="1" clause_i="57"/>
+      <name name="system_info" arity="1" clause_i="58"/>
+      <name name="system_info" arity="1" clause_i="59"/>
+      <name name="system_info" arity="1" clause_i="60"/>
+      <name name="system_info" arity="1" clause_i="61"/>
+      <name name="system_info" arity="1" clause_i="62"/>
+      <name name="system_info" arity="1" clause_i="63"/>
+      <name name="system_info" arity="1" clause_i="64"/>
       <fsummary>Information about the system</fsummary>
       <desc>
         <p>Returns various information about the current system
@@ -6163,6 +6411,57 @@ ok
 	    documentation of versions in the system principles
 	    guide</seealso>.</p>
           </item>
+          <tag><marker id="system_info_os_monotonic_time_source"><c>os_monotonic_time_source</c></marker></tag>
+          <item>
+            <p>Returns a list containing information about the source of
+	    <seealso marker="erts:time_correction#OS_Monotonic_Time">OS
+	    monotonic time</seealso> that is used by the runtime system.</p>
+	    <p>In case <c>[]</c> is returned, no OS monotonic time is
+	    available. The list contains two-tuples with <c>Key</c>s
+	    as first element, and <c>Value</c>s as second element. The
+	    order if these tuples is undefined. Currently the following
+	    tuples may be part of the list, but more tuples may be
+	    introduced in the future:</p>
+	    <taglist>
+	      <tag><c>{function, Function}</c></tag>
+	      <item><p><c>Function</c> is the name of the funcion
+	      used. This tuple always exist if OS monotonic time is
+	      available to the runtime system.</p></item>
+
+	      <tag><c>{clock_id, ClockId}</c></tag>
+	      <item><p>This tuple only exist if <c>Function</c>
+	      can be used with different clocks. <c>ClockId</c>
+	      corresponds to the clock identifer used when calling
+	      <c>Function</c>.</p></item>
+
+	      <tag><c>{resolution, OsMonotonicTimeResolution}</c></tag>
+	      <item><p>Highest possible resolution of current
+	      OS monotonic time source as parts per second. If
+	      no resolution information can be retreived from
+	      the OS, <c>OsMonotonicTimeResolution</c> will be
+	      set to the resolution of the time unit of
+	      <c>Function</c>s return value. That is, the actual
+	      resolution may be lower than
+	      <c>OsMonotonicTimeResolution</c>. Also note that
+	      the resolution does not say anything about the
+	      accuracy, and that the precision might not align
+	      with the resolution. You do, however, know that the
+	      precision won't be higher than
+	      <c>OsMonotonicTimeResolution</c>.</p></item>
+
+	      <tag><c>{parallel, Parallel}</c></tag>
+	      <item><p><c>Parallel</c> equals <c>yes</c> if
+	      <c>Function</c> is called in parallel from multiple
+	      threads. If it is not called in parallel, because
+	      calls needs to be serialized, <c>Parallel</c> equals
+	      <c>no</c>.</p></item>
+
+	      <tag><c>{time, OsMonotonicTime}</c></tag>
+	      <item><p><c>OsMonotonicTime</c> equals current OS
+	      monotonic time in <c>native</c>
+	      <seealso marker="#type_time_unit">time unit</seealso>.</p></item>
+	    </taglist>
+          </item>
 	  <tag><marker id="system_info_port_parallelism"><c>port_parallelism</c></marker></tag>
 	  <item><p>Returns the default port parallelism scheduling hint used.
 	  For more information see the
@@ -6288,6 +6587,11 @@ ok
             <p>Returns <c>true</c> if the emulator has been compiled
               with smp support; otherwise, <c>false</c>.</p>
           </item>
+	  <tag><marker id="system_info_start_time"/><c>start_time</c></tag>
+	  <item><p>The <seealso marker="#monotonic_time/0">Erlang monotonic
+	  time</seealso> in <c>native</c>
+	  <seealso marker="#type_time_unit">time unit</seealso> at the
+	  time when current Erlang runtime system instance started.</p></item>
           <tag><c>system_version</c></tag>
           <item>
             <p>Returns a string containing version number and
@@ -6311,12 +6615,64 @@ ok
               (<seealso marker="erts:erl_driver#driver_async">driver_async()</seealso>)
               as an integer.</p>
           </item>
+	  <tag><marker id="system_info_time_correction"/><c>time_correction</c></tag>
+	  <item><p>Returns a boolean value indicating whether
+	  <seealso marker="time_correction#Time_Correction">time correction</seealso>
+	  is enabled or not.
+	  </p></item>
+	  <tag><marker id="system_info_time_offset"/><c>time_offset</c></tag>
+	  <item><p>Returns the state of the time offset:</p>
+	  <taglist>
+	    <tag><c>preliminary</c></tag>
+	    <item><p>The time offset is preliminary, and will be changed
+	    at a later time when being finalized. The preliminary time offset
+	    is used during the preliminary phase of the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso>.</p></item>
+
+	    <tag><c>final</c></tag>
+	    <item><p>The time offset is final. This
+	    either due to the use of the
+	    <seealso marker="time_correction#No_Time_Warp_Mode">no
+	    time warp mode</seealso>, or due to the time offset having
+	    been finalized when using the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso>.</p></item>
+
+	    <tag><c>volatile</c></tag>
+	    <item><p>The time offset is volatile. That is, it may
+	    change at any time. This due to the
+	    <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso> being used.</p></item>
+	  </taglist>
+	  </item>
+	  <tag><marker id="system_info_time_warp_mode"/><c>time_warp_mode</c></tag>
+	  <item><p>Returns a value identifying the
+	  <seealso marker="time_correction#Time_Warp_Modes">time warp
+	  mode</seealso> being used:</p>
+	  <taglist>
+	    <tag><c>no_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#No_Time_Warp_Mode">no
+	    time warp mode</seealso> is being used.</p></item>
+
+	    <tag><c>single_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso> is being used.</p></item>
+
+	    <tag><c>multi_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso> is being used.</p></item>
+	  </taglist>
+	  </item>
           <tag><marker id="system_info_tolerant_timeofday"><c>tolerant_timeofday</c></marker></tag>
           <item>
-            <p>Returns whether compensation for sudden changes of system
-              time is <c>enabled</c> or <c>disabled</c>.</p>
-            <p>See also <seealso marker="erts:erl#+c">+c</seealso>
-              command line flag.</p>
+            <p>Returns whether a pre erts-7.0 backwards compatible compensation
+	    for sudden changes of system time is <c>enabled</c> or <c>disabled</c>.
+	    Such compensation is <c>enabled</c> when the
+	    <seealso marker="#system_info_time_offset">time offset</seealso> is
+	    <c>final</c>, and
+	    <seealso marker="#system_info_time_correction">time correction</seealso>
+	    is enabled.</p>
           </item>
           <tag><c>trace_control_word</c></tag>
           <item>
@@ -6595,7 +6951,44 @@ ok
         </note>
       </desc>
     </func>
+    <func>
+      <name name="system_time" arity="0"/>
+      <fsummary>Current Erlang system time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	in <c>native</c>
+	<seealso marker="#type_time_unit">time unit</seealso>.</p>
 
+	<p>Calling <c>erlang:system_time()</c> is equivalent to: 
+	<seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c>
+	+
+        </c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+    </func>
+    <func>
+      <name name="system_time" arity="1"/>
+      <fsummary>Current Erlang system time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	converted into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Calling <c>erlang:system_time(<anno>Unit</anno>)</c> is equivalent to: 
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#system_time/0"><c>erlang:system_time()</c></seealso><c>,
+	native, <anno>Unit</anno>)</c>.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+    </func>
     <func>
       <name name="term_to_binary" arity="1"/>
       <fsummary>Encode a term to an Erlang external term format binary</fsummary>
@@ -6672,6 +7065,88 @@ ok
       </desc>
     </func>
     <func>
+      <name name="time_offset" arity="0"/>
+      <fsummary>Current time offset</fsummary>
+      <desc>
+	<p>Returns the current time offset between
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso>
+	and
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> in
+	<c>native</c> <seealso marker="#type_time_unit">time unit</seealso>.
+	Current time offset added to an Erlang monotonic time gives
+	corresponding Erlang system time.</p>
+
+	<p>The time offset may or may not change during operation depending
+	on the <seealso marker="time_correction#Time_Warp_Modes">time
+	warp mode</seealso> used.</p>
+
+	<note>
+	  <p>A change in time offset may be observed at slightly
+	  different points in time by different processes.</p>
+
+	  <p>If the runtime system is in
+	  <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	  time warp mode</seealso>, the time offset will be changed when
+	  the runtime system detects that the
+	  <seealso marker="time_correction#OS_System_Time">OS system
+	  time</seealso> has changed. The runtime system will, however,
+	  not detect this immediately when it happens. A task checking
+	  the time offset is scheduled to execute at least once a minute,
+	  so under normal operation this should be detected within a
+	  minute, but during heavy load it might take longer time.</p>
+	</note>
+      </desc>
+    </func>
+    <func>
+      <name name="time_offset" arity="1"/>
+      <fsummary>Current time offset</fsummary>
+      <desc>
+	<p>Returns the current time offset between
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso>
+	and
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	converted into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Same as calling	
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso><c>, native, <anno>Unit</anno>)</c>
+	however optimized for commonly used <c><anno>Unit</anno></c>s.</p>
+      </desc>
+    </func>
+    <func>
+      <name name="timestamp" arity="0"/>
+      <type name="timestamp"/>
+      <fsummary>Current Erlang System time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	on the format <c>{MegaSecs, Secs, MicroSecs}</c>. This format is 
+	the same that <seealso marker="kernel:os#timestamp/0"><c>os:timestamp/0</c></seealso>
+	and the now deprecated <seealso marker="#now/0"><c>erlang:now/0</c></seealso>
+	uses. The reason for the existence of <c>erlang:timestamp()</c> is
+	purely to simplify usage for existing code that assumes this timestamp
+	format. Current Erlang system time can more efficiently be retrieved in
+	the time unit of your choice using
+	<seealso marker="#system_time/1"><c>erlang:system_time/1</c></seealso>.</p>
+
+	<p>The <c>erlang:timestamp()</c> BIF is equivalent to:</p><code type="none">
+timestamp() ->
+    ErlangSystemTime = erlang:system_time(micro_seconds),
+    MegaSecs = ErlangSystemTime div 1000000000000,
+    Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000,
+    MicroSecs = ErlangSystemTime rem 1000000,
+    {MegaSecs, Secs, MicroSecs}.</code>
+        <p>It however use a native implementation which does
+	not build garbage on the heap and with slightly better
+	performance.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+
+    </func>
+    <func>
       <name name="tl" arity="1"/>
       <fsummary>Tail of a list</fsummary>
       <desc>
@@ -7436,6 +7911,100 @@ ok
       </desc>
     </func>
     <func>
+      <name name="unique_integer" arity="0"/>
+      <fsummary>Get a unique integer value</fsummary>
+      <desc>
+	<p>Generates and returns an
+	<seealso marker="doc/efficiency_guide:advanced#unique_integers">integer
+	unique on current runtime system instance</seealso>. The same as calling
+	<seealso marker="#unique_integer/1"><c>erlang:unique_integer([])</c></seealso>.</p>
+      </desc>
+    </func>
+    <func>
+      <name name="unique_integer" arity="1"/>
+      <fsummary>Get a unique integer value</fsummary>
+      <desc>
+	<p>Generates and returns an
+	<seealso marker="doc/efficiency_guide:advanced#unique_integers">integer
+	unique on current runtime system
+	instance</seealso>. The integer is unique in the
+	sense that this BIF, using the same set of
+	modifiers, will not return the same integer more
+	than once on the current runtime system instance.
+	Each integer value can of course be constructed
+	by other means.</p>
+
+	<p>By default, i.e. when <c>[]</c> is passed as
+	<c><anno>ModifierList</anno></c>, both negative and
+	positive integers will be returned. This is order
+	to be able to utilize the range of integers that do
+	not need to be heap allocated as much as possible.
+	By default the returned integers are also only
+	guaranteed to be unique, i.e., any integer returned
+	may be either smaller, or larger than previously
+	returned integers.</p>
+
+	<p>Currently valid <c><anno>Modifier</anno></c>s:</p>
+	<taglist>
+
+	  <tag>positive</tag>
+	  <item><p>Return only positive integers.</p>
+	  <p>Note that by passing the <c>positive</c> modifier
+	  you will get heap allocated integers (big-nums)
+	  quicker.</p>
+	  </item>
+
+	  <tag>monotonic</tag>
+	  <item><p>Return
+	  <seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly
+	  monotonically increasing</seealso> integers
+	  corresponding to creation time. That is, the integer
+	  returned will always be larger than previously
+	  returned integers on the current runtime system
+	  instance.</p>
+	  <p>These values can be used when ordering events
+	  on the runtime system instance. That is, if both
+	  <c>X = erlang:unique_integer([monotonic])</c> and
+	  <c>Y = erlang:unique_integer([monotonic])</c> are
+	  executed by different processes (or the same
+	  process) on the same runtime system instance and
+	  <c>X &lt; Y</c> we know that <c>X</c> was created
+	  before <c>Y</c>.</p>
+	  <warning><p>Strictly monotonically increasing values
+	  are inherently quite expensive to generate and scales
+	  poorly. This since the values needs to be
+	  synchronized. That is, do not pass the <c>monotonic</c>
+	  modifier unless you really need strictly monotonically
+	  increasing values.</p></warning>
+	  </item>
+
+	</taglist>
+
+	<p>All currently valid <c><anno>Modifier</anno></c>s
+	can be combined. Repeated (valid)
+	<c><anno>Modifier</anno></c>s in the <c>ModifierList</c>
+	are ignored.</p>
+
+	<note><p>Note that the set of integers returned by
+	<c>unique_integer/1</c> using diffrent sets of
+	<c><anno>Modifier</anno></c>s <em>will overlap</em>.
+	For example, by calling	<c>unique_integer([monotonic])</c>,
+	and <c>unique_integer([positive, monotonic])</c>
+	repeatedly, you will eventually see some integers being
+	returned by both calls.</p></note>
+
+        <p>Failures:</p>
+	<taglist>
+	  <tag><c>badarg</c></tag>
+	  <item>if <c><anno>ModifierList</anno></c> is not a
+	  proper list.</item>
+	  <tag><c>badarg</c></tag>
+	  <item>if <c><anno>Modifier</anno></c> is not a
+	  valid modifier.</item>
+	</taglist>
+      </desc>
+    </func>
+    <func>
       <name name="unlink" arity="1"/>
       <fsummary>Remove a link, if there is one, to another process or port</fsummary>
       <desc>