[LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Gerard Ashton
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

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Tony Finch
On Tue, 17 Feb 2009, Gerard Ashton wrote: 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) 2. It has all the

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread M. Warner Losh
In message: f21e028c02794c7bb6cba28e2...@grendel Gerard Ashton ashto...@comcast.net writes: :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)

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Rob Seaman
The URL to the OASIS document didn't work for me, so it's hard to evaluate the reasoning behind the choice of format here. What exactly is the use case they are trying to satisfy? That said, I'm with Tony. This seems like what ISO 8601 was designed for. If not ISO 8601, how about

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Clive D.W. Feather
Poul-Henning Kamp said: It would have been even better to write: An ISO C time_t timestamp. ISO C doesn't define the type, format, or meaning of time_t - it can even be floating point or (IIRC) a structure. -- Clive D.W. Feather | If you lie to the compiler, cl...@davros.org

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Poul-Henning Kamp
In message 20090217210518.gd91...@davros.org, Clive D.W. Feather writes: Poul-Henning Kamp said: ISO C doesn't define the type, format, or meaning of time_t - it can even be floating point or (IIRC) a structure. No, it must be an arithmetic type. Okay (I didn't have the standard in front of

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Clive D.W. Feather
Poul-Henning Kamp said: ISO C doesn't define the type, format, or meaning of time_t - it can even be floating point or (IIRC) a structure. Okay (I didn't have the standard in front of me). That still allows floating point. And that wouldn't matter, the objective is to make a random number.

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Steve Allen
On Tue 2009-02-17T20:53:43 +, Poul-Henning Kamp hath writ: This is a variant of the UUID madness that somebody came up with because they didn't want to run a registry or use the existing well-structured process (ISO OID's) and though that the eventual collisions probably doesn't matter

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Gerard Ashton
, 2009 3:48 PM To: Leap Second Discussion List Subject: Re: [LEAPSECS] A new use for Pre-1972 UTC The URL to the OASIS document didn't work for me ... ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Gerard Ashton
Rob Seaman wrote in part: Creating an ID that is guaranteed unique is not a trivial task, especially if (as one suspects is true here) a central server is out of the question. I'm not familiar with the details of OID, but in general, it would be desireable to have the option to

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Joseph M Gwinn
leapsecs-boun...@leapsecond.com wrote on 02/17/2009 04:17:20 PM: On Tue 2009-02-17T20:53:43 +, Poul-Henning Kamp hath writ: This is a variant of the UUID madness that somebody came up with because they didn't want to run a registry or use the existing well-structured process (ISO

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Rob Seaman
They avoid the issue by piggybacking on the current model. A Notary Public has a commission assigned by some locale. I'll take their word for it that this breaks down by country/state. (One could wish they called this province or locale or some such.) The SHA disambiguates the case of

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Rob Seaman
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

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Gerard Ashton
Rob Seaman wrote in part: 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 Notaries are usually allowed to

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Rob Seaman
Gerard Ashton wrote: (I deliberately didn't say county or parish since I think Louisiana is one of the exceptions.) And of course, four of the states are actually commonwealths :-) Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com

Re: [LEAPSECS] A new use for Pre-1972 UTC

2009-02-17 Thread Daniel R. Tobias
On 17 Feb 2009 at 14:27, Rob Seaman wrote: Creating an ID that is guaranteed unique is not a trivial task, especially if (as one suspects is true here) a central server is out of the question. If the ID includes as one of its elements a fully qualified domain name, and the owner/operator