[LEAPSECS] A new use for Pre-1972 UTC

Rob Seaman seaman at noao.edu
Tue Feb 17 17:50:39 EST 2009


Poul-Henning Kamp wrote:


> And that would be perfect, because then there is even less chance of

> you creating a random identifier that is identical to mine.

>

> Remember, this is a write-only timestamp, its only purpose is to

> provide time-changing bits. What those bits mean does not matter.


There is already zero chance since the timestamp is attached to
SHA-256. If there is no requirement to provide a human readable
timestamp, they should omit it.

Rather, as with the fields identifying the notary and document name,
the timestamp is fodder for list handling. It will allow sorting the
list, and should allow grabbing specific dates from the list if they
don't obscure it too much. The key issue with dates (as opposed to
epochs) is whether local or UT is more pertinent. If these were human
notaries, a strong argument could be made for local time since
resolution at the level of a particular calendar date will often be
required.

Actually, there is a failure of the current scheme in the document. A
notary is per country/state pair. But about a third of the U.S.
states and presumably many provinces in other countries are split by
timezones. A particular notary can therefore be expected to roam over
more than one timezone. Even if they demand a UTC timestamp, there is
no likelihood that such an itinerant authority will accommodate this
correctly. For instance, imagine a Notary working out of the back of
a Winnebago up and down an E/W highway. Are they likely to reset the
timezone appropriately on their laptop?

Rob



More information about the LEAPSECS mailing list