>Hi,
>
>I just realised there is nothing to get 'Internet Time' in Squeak.
>If I write the code, what will I have to do to submit it for updation in the
>final image?
>
>~Mayuresh

also see
http://minnow.cc.gatech.edu/squeak/1076

and a previous  note on the subject.

At 10:50 PM -0800 11/20/01, John M McIntosh wrote:
>go ask my friendly time server what the time is.
>
>	| serverAddr s |
>	Socket initializeNetworkIfFail: [^self error: 'Failed to init 
>network'].
>	serverAddr _ NetNameResolver addressForName: 
>'time-a.nist.gov' timeout: 10.
>	serverAddr = nil ifTrue: [self error: 'Could not find the 
>address for time-a.nist.gov'].
>	s _ Socket new.
>	s connectTo: serverAddr port: 13. 
>	s waitForConnectionUntil: (self deadlineSecs: 15).
>	Transcript show: 'the time server reports: ' , s 
>getResponseNoLF,' at time ',Time now printString;cr.
>	s closeAndDestroy.
>
>
>Try it,
>
>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

Also you should note if your VM supports UUID as a primitive then 
this note can apply
At 12:28 PM -0800 11/21/01, John M McIntosh wrote:
>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
===========================================================================