On Tue, Nov 20, 2001 at 10:50:04PM -0800, John M McIntosh wrote:
> 
> the time server reports: 52234 01-11-21 05:33:07 00 0 0 599.9 
> UTC(NIST) *  at time 9:33:06 pm
> 
> See http://www.boulder.nist.gov/timefreq/service/its.htm
> 
> then do some messy math and roughly estimate the time zone I'm in and 
> go from there... This assume the silly system clock is oh 5 to 10 
> minutes within the real time I'd guess, actually it doesn't matter 
> the math + or - will allow me to back calculate the UTC time. MMm I 
> could go with port 37 and get the seconds since 1900, that might be 
> easier, then get the seconds in squeak since 1901
> 
> Mm but what about that millisecond clock, a distraction.. Let see on 
> the mac the internal nanosecond clock will wrap after count 
> milliseconds for 24.855 days (2147483647 milliseconds).I'm not sure 
> I've have an image up that long in a test environment so I'm unsure 
> what it means. However but since the millisecond clock is returned as 
> smallinteger it only can span 536870911 milliseconds or 6.213 days. 
> Which is the limit for a millisecond interval btw. MMM I wonder if 
> anyone has tested that... yes a distraction.
> 
> Maybe there is an OS call to get the timezone you are in and I'll 
> punt to the VM  maintainers eh?
> 
> Sigh of course machines aren't required to be connected to the internet...
> -- 

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.

If that is the case, then you can forget about time zones entirely,
since the time server is giving you the time in UTC already. All you
need is the logic to count the seconds back to 1970, including
leap years and leap seconds (well, OK, we can overlook the leap
seconds). But I think you can avoid that also; I took a quick look
that the web page you pointed to, and it says that RFC-868 and
RFC-1305 are both supported by their internet time servers, and both
protocols can give you time in seconds since 1970 directly. So if
you do an internet time lookup, the right thing to do would be
to open a socket at grab the time with one of those two protocols.

Here are some key points:
1) Time zones are a real mess.  They are much more complicated than
you might expect.  Don't use them if you can possibly help it!
Stick with a geography-independent representation of time
(such as "time at UTC") and you are much better off.

2) As a practical matter, if you were to assume that all Squeak
images are running in the same time zone (as if all those computers
were physically piled up near the Greenwich date line), you will
probably still get unique UUID values.

3) Remember that FilePlugin needs to set a 32 bit session identifier
at the time it opens its first file (the changes and sources files).
If the UUID based session identifier is calculated later, then ... well,
we'll figure something out.

Dave