W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

FW: [Moderator Action] WebDAV: UUID/GUID - Please check my math!

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Sun, 15 Aug 1999 16:08:41 -0700
To: WebDAV WG <w3c-dist-auth@w3.org>
Caught by the spam filter...

- Jim

-----Original Message-----
From: Dennis E. Hamilton [mailto:orcmid@email.msn.com]On Behalf Of
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

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



	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


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
- - - - - - - - - - - - - - - -
tel. +1(650)938.4584
fax. +1(650)567.9846


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


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


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.


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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:17 UTC