[LEAPSECS] A new use for Pre-1972 UTC
Gerard Ashton
ashtongj at comcast.net
Tue Feb 17 15:08:18 EST 2009
Oasis will soon present for public review "eNotarization Markup Language
(ENML)
Version 1.0" which is a proposed standard to represent a notarized document
in
XML. It is available in several formats at
http://www.oasis-open.org/committees/documents.php?wg_abbrev=legalxml-enotar
y
One of the requirements of the standard is to label certain portions of the
document with an ID that will, in all probability, be globally unique.
Several
fields are concatenated together to form what the authors hope will be a
unique id, and one of the fields is defined as follows (p. 175):
Concatenate the "epoch" time at the time this ID value is being
generated ; the "epoch" time is the number of seconds elapsed since
00:00:00 Coordinated Universal Time (UTC) January 01,
1970 (not counting leap seconds)
Since this is only being used to generate a unique value, the accuracy of
the value is not as important as it otherwise might be, but I observe the
following issues:
1. Although the present version of the standard only uses the value for
uniqueness, standards are often extended, and poor initial definitions
inhibit
useful extensions.
2. It has all the problems of what UTC means before 1972 that have been
discussed
in this mailing list, as well as what kind of seconds are intended.
3. Unlike the POSIX standard, it presents no algorithm to convert a
contemporary
UTC time and date to a field value.
4. "'epoch' time" is a strange phrase in this context.
5. Despite the limited purpose of the value, those interpreting documents
that
conform to the standard may decide to process the value and treat the time
as if it were legally meaningful.
I suspect the goals of the authors were to define the field so that
A. Is directly available as an object in the authors' preferred programming
environment, which I believe is Java Beans,
B. If need be, can be interpreted without specialized computer software.
Maybe there is a way to generate a random number instead of a time that
would serve
the same purpose, but defining such a random number generator and
interpreting the
results without access to the computer that generated it might be a problem.
I'm not aware of any time scale that meets all the following requirements:
a. Rigorously defined epoch, rigorous definition of whether SI or UT1 second
is used.
b. Directly available in most programming environments.
c. Contains a minimal number of non-alphanumeric characters to facilitate
parsing.
d. The same time will be represented identically, character-for-character,
in all
implementations.
If such a time scale existed, it would make a good replacement for the
definition
in the standard.
Since postings to a mailing list carry little weight, it would be better if
any
objections to the proposed standard could be substantiated in an
authoritative
source.
Thoughts?
Gerry Ashton
More information about the LEAPSECS
mailing list