Well, maybe not so effective after all, given that the commit notice
for Monticello-dtl.727 on the mailing list still exhibits the same problem.

Dave

On Mon, Sep 07, 2020 at 07:52:02PM -0400, David T. Lewis wrote:
> A crude but effective fix is in the inbox in Monticello-dtl.727
> 
> Dave
> 
> On Mon, Sep 07, 2020 at 03:56:19AM +0200, Levente Uzonyi wrote:
> > Hi Eliot,
> > 
> > 
> > The Monticello history of the Chronology package says that 
> > those microseconds were introduced by Kernel-eem.970:
> > 
> > >Changes to Time and Delay prior to changing over to the utc microsecond 
> > >clock and its use in delay scheduling.
> > 
> > The "offending" change is probably the following:
> > 
> > Item was changed:
> >   ----- Method: Time class>>now (in category 'ansi protocol') -----
> >   now
> >   "Answer a Time representing the time right now - this is a 24 hour 
> > clock."
> > + | localUsecs localUsecsToday |
> > + localUsecs := self localMicrosecondClock.
> > + localUsecsToday := localUsecs \\ MicrosecondsInDay.
> > + ^ self
> > + seconds: localUsecsToday // 1000000
> > + nanoSeconds: localUsecsToday \\ 1000000 * 1000!
> > -
> > - | ms |
> > -
> > - ms := self milliSecondsSinceMidnight.
> > -
> > - ^ self seconds:  (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000
> > -
> > -
> > - !
> > 
> > And that happened more than four and a half years ago.
> > 
> > 
> > Levente
> > 
> > On Sun, 6 Sep 2020, Eliot Miranda wrote:
> > 
> > >Name: VMMaker.oscog-eem.2800
> > >Author: eem
> > >Time: 6 September 2020, 4:58:47.598839 pm
> > >UUID: a6116113-df13-435d-968d-e9b111676754
> > >Ancestors: VMMaker.oscog-eem.2799
> > >
> > >Seriously ?!??! ;-)
> > >_,,,^..^,,,_
> > >best,??Eliot
> > >
> > >
> 
> > 
> 
>