As stated in Microsoft's documentation for the Java programming language, in the Date class, "Nearly all modern operating systems assume that 1 day = = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a 'leap second.'" It goes on to state "A second is represented by an integer from 0 to 61. The values 60 and 61 will occur only for leap seconds, and even then only in Java implementations that actually track leap seconds correctly. " The possibility of a leap second is unusual; similar programming provisions in other computer languages, such as JavaScript and C# consider a minute to always consist of 60 seconds. Nevertheless, most operating systems and programming language will display human-readable times with the abbreviation UTC, even though the lack of leap seconds means these times are fundamentally different from UTC. A better abbreviation would be UT, for "Universal Time", since these always-60-seconds-in-a-minute time scales attempt to approximate mean solar time at Greenwich, even if they use UTC as an intermediate step.
Most modern versions of UNIX attempt to comply with the POSIX standard. The rational chapter of the current standard has a "Seconds since the Epoch" section which states
Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.
As of September 2000, 24 leap seconds had been added to UTC since the Epoch, 1 January, 1970. Historically, one leap second is added every 15 months on average, so this offset can be expected to grow steadily with time.
The section goes on to say that it is the responsibility of the vendor and administrator of a system to insure the seconds since the Epoch value be as close as "as necessary for the application being run on that system."
The section also says "It is important that the interpretation of time names and seconds since the Epoch values be consistent across conforming systems; that is, it is important that all conforming systems interpret "536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986, regardless of the accuracy of the system's idea of the current time."
The section also states that the decision to ignore leap seconds was discussed on a number of occasions, and while the final decision was to ignore them, there was considerable dissent. The length of theresulting second "as measured by some external standard is not specified." Also, "those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best."
The OASIS ENML Version 1.0 Draft 01 (hereinafter ENML) defines an epoch, "the 'epoch' time is the number of seconds elapsed since 00:00:00 Coordinated Universal Time (UTC) January 01, 1970 (not counting leap seconds)". This is a condensed version of the definition one finds in descriptions of Unix time related functions and the JavaScript language. Unix time-related decisions were made in an era of computers with inaccurate clocks, each computer standing alone with minimal networking. A desire was to not overwhelm system administrators with details about seconds when, in practice, it was doubtful whether a particular computer clock was within a minute of the correct time. Therefore, sloppy decisions were made and the above ENML definition follows this sloppy tradition. In particular:
In view of the difficulty of finding information about exactly how various computing platforms handle leap seconds, and the fact that various computing platforms handle it differently, various programmers attempting to implement ENML may interpret the definition differently, and may produce code with increasingly different behavior.
The discussion of the POSIX standard above makes it plain that that group values consistent transformation between seconds-since-the-Epoch values and broken down time-dates (e.g. 59 seconds, 59 minutes, 23 hours 31 December 1986) above the absolute accuracy of the time.
The addition of the ID time to the ID is stated to be for the purpose of insuring the ID is unique. It is not clear whether there are known situations where the ID would be non-unique were it not for the ID time, or whether the addition of the ID time is just a precaution. Assuming for the sake of discussion that there is a circumstance where a non-unique ID would occur without the ID time, that scenario should be studied in detail to see if a granularity of one second is small enough. One could imagine a human notary performing all the necessary human interaction (which would require much more than one second) and then launch an automated process that could perform several electronic notarizations in one second.
theepoch timeID time is the number of seconds elapsed since 00:00:00Coordinated Universal Time(UTC) January 01, 1970 (not countingUniversal Time does not contain leap seconds). Applications should be designed to tolerate the use of UTC as an approximation to UT and to tolerate computer clock errors of a few minutes.
By using a time scale, Universal Time, that does not use leap seconds, and specifically stating so, every implementer will know that every minute always contains 60 seconds and every day always contains 86,400 seconds. The precise difference between UT and UTC need not be known for the purpose of notarizing documents, and especially not for a value that is merely used to make sure ID attributes are unique. All that is necessary is a definition that is unambiguous and easy to explain, so that it will be implemented consistently.
I believe this definition is also in accord with the views of Steve Allen of the UCO/Lick Observatory who wrote on his web site
Despite the claim of the POSIX text that Unix system time is UTC, in reality it is more accurately categorized as just plain Universal Time (UT). It does not conform to the specifications of Coordinated Universal Time (UTC) so long as UTC continues to have leap seconds.
If one assumes that notaries will work with one signer and one document at a time, the time required for human interaction will assure that no two documents have the same ID time. However, consider the scenario of administering an oath of office to a large group of new officials. The notary might have everyone in the group speak the oath orally together, line up and sign the electronic document, and then notarize all the oaths as a batch. Such processing might lead to documents with the same ID time.
It is my understanding that Lousiana notaries are commissioned for life, and so do not have commission expiration dates. Also, in the several states, officials other than notaries public may have the same powers as a notary, but may not have any fixed expiration for their term of office.