On Wed, Jan 13, 2016 at 05:34:07PM -0800, tim Rowledge wrote:
> 
> > On 14-01-2016, at 1:10 AM, commits at source.squeak.org wrote:
> > 
> > tim Rowledge uploaded a new version of Morphic to project The Trunk:
> > http://source.squeak.org/trunk/Morphic-tpr.1067.mcz
> > 
> > ==================== Summary ====================
> > 
> > Name: Morphic-tpr.1067
> > Author: tpr
> > Time: 14 January 2016, 5:09:31.880065 pm
> > UUID: 9f5c0b23-31d9-4698-99ba-588068d5e268
> > Ancestors: Morphic-mt.1066
> > 
> > Use the new Time class>eventMillisecondClock method to get a fake timestamp for places where we have to fake up an event and want to compare its timestamp with a real event.
> 
> This seems to mostly solve the problem but I???m not really happy with seeing ???clicktimeout??? notifications in the ClickExerciserMorph after a fast click-release. 
> 

I don't know if you have it perfect, but your approach makes sense for now.
The millisecond clock is/was by definition an arbitrary value that should
be expected to roll over periodically. There is no expectation that it be
tied to e.g. the Smalltalk or Posix epoch. If we can fix things up in the
VM such that it /does/ align with a sensible time scale, that's great, but
in the mean time it is probably better if the image does not depend on it.

There are enough dependencies on 32 bit event time stamps to preserve that
behavior. Assuming that event times are given with millisecond resolution,
there is no need to provide a large time scale range. So for events, a
32-bit time stamp is fine, millisecond resolution is reasonable, and existing
data structures for events are ok.

+1 for #eventMillisecondClock.

Dave