From: Jim Whitehead <ejw@ics.uci.edu>

Date: Sun, 15 Aug 1999 16:08:41 -0700

To: WebDAV WG <w3c-dist-auth@w3.org>

Message-ID: <NDBBIKLAGLCOPGKGADOJEEPJCCAA.ejw@ics.uci.edu>

Date: Sun, 15 Aug 1999 16:08:41 -0700

To: WebDAV WG <w3c-dist-auth@w3.org>

Message-ID: <NDBBIKLAGLCOPGKGADOJEEPJCCAA.ejw@ics.uci.edu>

Caught by the spam filter... - Jim -----Original Message----- From: Dennis E. Hamilton [mailto:orcmid@email.msn.com]On Behalf Of infonuovo@email.com Sent: Tuesday, August 10, 1999 10:49 PM To: WebDAV Discussion List (E-mail) Cc: Alan Babich (E-mail); Chuck Fay (E-mail); Jim Green (E-mail); John F. Greene Jr. (E-mail); Katsumi Kanasaki (E-mail); Mitsuru Akizawa (E-mail); Richard Sauvain (E-mail); Steve Cousins (E-mail) Subject: [Moderator Action] WebDAV: UUID/GUID - Please check my math! %To: WebDAV Discussion List %Cc: DMA CSDocs Subcommittee %From: Dennis E. Hamilton %Re: UUID/GUID - Please check my math! In the DMA work on compound/structured documents, we are using UUID/GUID values for unambiguously identifying distinguished elements of persistent material. I followed the lead in RFC 2518 and did some research into UUID/GUID schemes. I wanted to make sure I could describe the conditions where someone could safely reserve a 32-bit block of Ids for suballocation as part of some specialized application (e.g., generating UUIDs for locally-unique elements of a legacy system). What I came up with is at http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#StandardDmaId MATH QUESTION According to my arithmetic, a timestamp employing a 60-bit 100ns interval counter will take over 3,653 years to repeat. Since DCE UUIDs are origined at 00:00 on October 15, 1582 A.D of the current calendar system, it looks like we will get FAR beyond 3400AD without a timestamp repetition. I have repeated this calculation several times and I get the same answer: 2^60 * 0.1 microsecond is over 3,653 years. (Or (1<<60) * 10E-7 seconds) I've included the relevant passage below (from http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#UUIDTimeStamp) although the formulas aren't as nice as in HTML. Can someone please check this for me. And does anyone know where the 3400AD determination came from? (It's true that the timestamp can be smaller for different Variant fields. But the DCE variant field only takes away 2 bits from time-hi.) -- Dennis Dennis E. Hamilton - - - - - - - - - - - - - - - - mailto:infonuovo@email.com tel. +1(650)938.4584 fax. +1(650)567.9846 http://www.infonuovo.com UUID TIME STAMP: TIME-LOW, TIME-MID, TIME-HI ------------------------------------------ The time stamp values correspond to the number of 100-nanosecond intervals that have occurred since the initiation of the current Gregorian calendar on October 15, 1582 A.D of that calendar. The 60 bits are expressed in three parts: time-low (32 bits), time-mid (16 bits), and time-hi (12 bits). The integer value of the time stamp is (time-hi × 2^16 + time-mid) × 2^32 + time-low It is not expected that time stamps be accurate to the nearest 100 nanoseconds. It is expected that time stamps generated with the same node and clock-seq values be monotonically increasing. There must be sufficient accuracy of time-keeping that duplication of identical time stamp and clock-seq combinations is statistically impossible for a given node identification. TIME-LOW The first group, consisting of 8 hexadecimal digits, specifies the value of a 32-bit unsigned binary integer, time-low. As a 100-nanosecond interval counter, time-low takes 429.4967296 seconds (about 7.16 minutes) before it repeats. TIME-MID The second group, consisting of 4 hexadecimal digits, specifies the value of a 16-bit unsigned binary integer, time-mid. The time-mid value advances each time time-low changes to 0. So time-mid changes every 429.4967296 seconds. It will take about 28,147,497.67 seconds, or about 7,818.75 hours, or about 325.78 days for time-mid to repeat. TIME-HI The third group, consisting of 4 hexadecimal digits, specifies the value of a 16-bit unsigned binary integer. The high-order nibble of 4 bits is used for a version field and the remaining 12 bits constitute the time-hi value. Since time-hi changes every 325.78 days, it will take 1,334,399.89 days, or over 3,653 years (4096 clicks of time-hi) for time-hi, and hence a value of the entire time stamp, to repeat. [end of extract]Received on Sunday, 15 August 1999 19:16:38 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 2 June 2009 18:43:51 GMT
*