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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs