[Vm-dev] microsecond timing for GC work

Andreas Raab andreas.raab at gmx.de
Wed Jan 20 02:42:27 UTC 2010


Hi David -

Sounds good to me - proceed for truth :-)

Cheers,
   - Andreas

David T. Lewis wrote:
>  
> On Tue, Jan 19, 2010 at 05:44:26PM -0800, Andreas Raab wrote:
>> David T. Lewis wrote:
>>> On Tue, Jan 19, 2010 at 04:28:47PM -0800, Andreas Raab wrote:
>>>>> Would anyone object to the addition of a primitive that answers
>>>>> Posix seconds (to some reasonable precision) plus time zone offset?
>>>>> This would be a named primitive in addition to John's microsecond
>>>>> primitive.
>>>> I'm not sure what the point of it would be. Both of you are speaking in 
>>>> riddles at this point; it would be good if you could spell out the 
>>>> issues more clearly.
>>> The clock in Squeak is done in local time (UTC translated to local
>>> seconds in the VM before it is reported to the image). Consider a
>>> Squeak image running in a locale with daylight savings time. Once
>>> per year in the fall, there is a period of one hour during which the
>>> Squeak clock has "jumped backwards" one hour. All of the values of the
>>> Squeak clock are repeated during for the next hour. The values are
>>> ambiguous, and the calculation of durations and times based on them
>>> is problematic.
>> Ah, I see. Thanks for clearing this up. How does that relate to posix 
>> seconds as stated above? Are posix seconds UTC? If not, shouldn't we 
>> rather make sure all time in UTC (regardless of epoch) and leave it to 
>> the image to work out the timezone it's in? That seems the better 
>> long-term option to me.
> 
> Wikipedia has a very good overview:
>   http://en.wikipedia.org/wiki/POSIX_time
>   http://en.wikipedia.org/wiki/Coordinated_Universal_Time
> 
> Yes, I meant the same thing by "Posix seconds" and "UTC".
> 
> The Smalltalk epoch is a constant number of seconds apart from the
> Posix epoch, although in Squeak it is not clear whether this should
> be measured from Palo Alto or from London. If you use the Posix epoch
> as the origin of your timeline and compute local time representation
> from UTC seconds and an offset corresponding to your own timezone,
> things just work.
> 
> Given the history of Squeak as a single user system with no awareness
> of time zones, it is easiest to think of the current Squeak clock
> as if the Smalltalk epoch was measured in your own local time zone,
> and just pretend that daylight savings transitions do not happen.
> That is perfectly sufficient for a single user computer (i.e.  99%
> of all Squeak users), but it's wrong if you need to handle time
> zones or calculate durations properly.
> 
> Dave
> 


More information about the Vm-dev mailing list