>
>I have not read the spec for UUID (sorry), but my guess would be that
>it is generated using the total number of elapsed seconds since some
>agreed time, probably 00:00:00 UTC, January 1, 1970.
>

Ok I read the fine print some more and realized that I think I can 
ignore the timestamp issue either by working with local time, or 
doing a UUID version 4 GUID. So from the docs:

The timestamp is a 60 bit value. For UUID version 1, this is 
represented by Coordinated Universal Time (UTC) as a count of 
100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date 
of Gregorian reform to the Christian calendar).

For systems that do not have UTC available, but do have local time, 
they MAY use local time instead of UTC, as long as they do so 
consistently throughout the system. This is NOT RECOMMENDED, however, 
and it should be noted that all that is needed to generate UTC, given 
local time, is a time zone offset.

For UUID version 3, it is a 60 bit value constructed from a name.

For UUID version 4, it is a randomly or pseudo-randomly generated 60 bit value.

So I think I'll do a version 4 UUID in Smalltalk and fall back to a 
system generated UUID if the hosting OS support it. This is way less 
complicated than dealing with the timestamp.


-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================