This is a discussion on ESRI : DRM Timestamp justifications, many good but NTP formats not even mentioned... - NTP ; UTCO: the offset (in seconds) between UTC and the Seconds value. The value is expressed as an unsigned 14-bit quantity. As of 2000-01-01 T 00:00:00 UTC, the value shall be zero and shall change as a result of each leap ...
UTCO: the offset (in seconds) between UTC and the Seconds value. The value
is expressed as an unsigned 14-bit
quantity. As of 2000-01-01 T 00:00:00 UTC, the value shall be zero and shall
change as a result of each leap second.
The value contained in this field shall have no effect on the time of
emission from the modulator.
Seconds: the number of SI seconds since 2000-01-01 T 00:00:00 UTC as an
unsigned 40-bit quantity.
Milliseconds: the number of milliseconds (1/1000th of an SI second) since
the time expressed in the Seconds field. The
value is expressed as an unsigned 10-bit quantity. The values 1 000 to 1 023
inclusive are reserved for future use.
DRM Timestamp: taken together, the Seconds and Milliseconds values produce
the DRM Timestamp value that
defines the time at which 50 % of the energy of the first time sample from
the IFFT of the first symbol of the DRM
transmission frame shall have been radiated on air.
Each subsequent MDI packet (as defined by the "dlfc" value, see clause
5.1.2) shall have a timestamp value which increases by 400 ms. The chosen
bit-widths allow DRM Timestamp to represent uniquely any date/time from 2
000 AD until approximately 34 800 AD with a resolution of one millisecond.
Conversion between DRM Timestamp and other standard time references is
outlined in annex B.
NOTE: The binary value of the combined DRM Timestamp field does not increase
uniformly due to the
modulo-1 000 milliseconds count.
It is the function of the DRM Multiplexer to allow sufficient time when
encoding this value to enable the longest
transmission path to deliver the data before it is required by the DRM
Modulator. All modulators supporting this TAG
Item shall provide at least ten seconds of buffering of MDI Packets.
== B.1 Relationships ==
The relationships between UTC, TAI, GPS Time and DRM Timestamp (as defined
in clause 5.2.2) are, as at the time of
writing (June 2003), as follows
.. GPS = TAI - 19 s (constant).
.. UTC = TAI - 32 s (variable due to leap seconds).
.. UTC = GPS - 13 s (variable due to leap seconds).
.. UTC = DRM - UTCO (constant due to varying value of UTCO).
.. DRM = TAI - 32 s (constant).
.. DRM = GPS - 13 s (constant).
.. DRM = UTC + UTCO (constant due to varying value of UTCO).
== B.2 Rationale ==
Several other standard time/date encodings are in common use, including MJD,
UTC, GPS. None of these adequately addressed the needs of a DRM system and
that it was desirable specifically for the DRM Timestamp.
The following reasons were given for rejecting other
.. MJD is subject to leap seconds making the fractional portion very hard to
.. UTC is subject to leap seconds making the number of seconds in a day
.. GPS Time is subject to "week number wrapping" approximately every 19,7
.. UTC, TAI, MJD and GPS Time all have epochs (start dates) partway through
The DRM Timestamp is not subject to leap seconds but contains sufficient
extra information trivially convert the value to UTC which does include
leap-seconds. Conversion to GPS simply involving the subtraction of a
constant value. The epoch for DRM Time is synchronized 400-year leap-year
cycle, making leap-year calculations simpler and less error prone.