[ntp:questions] ESRI : DRM Timestamp justifications, many good but NTP formats not even mentioned...

Max Power mikehack at u.washington.edu
Mon Dec 18 04:10:55 UTC 2006

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. 

More information about the questions mailing list