<div dir="auto">I am RSS.i will rto home server to pack my <div dir="auto">Tape backups in Kim 1 supertape format and take fruity 3.14 witm me to line star74464. z999 = 1935 a..d.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Synonym </div><div dir="auto"><br></div><div dir="auto">0 b.c. </div><div dir="auto">RSS</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 16, 2020, 8:47 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For purposes of closing out my original questions for this thread,<br>
conclusions are inline below.<br>
<br>
On Fri, Sep 11, 2020 at 05:54:16PM -0400, David T. Lewis wrote:<br>
> <br>
> This leads me to ask three questions:<br>
> <br>
> 1) Does #eventMillisecondClock need to exist? It looks like it might be<br>
> a kludge, if so could we make it go away?<br>
> <br>
<br>
No, eventMillisecondClock does not need to exist. Following recent updates<br>
in trunk, it is no longer used for anything related to event time stamps.<br>
<br>
<br>
> 2) If the eventMillisecondClock method does need to exist, should it be changed<br>
> to retrieve a millisecond value that is aligned with that of the events?<br>
> <br>
<br>
No. See above. No change is needed.<br>
<br>
<br>
> 3) If not 2) then do we need to change the Windows VM to somehow use event<br>
> timestamps that match eventMillisecondClock?<br>
> <br>
<br>
No. Event timestamps from the VM do not need to match eventMillisecondClock.<br>
The VM does not need to be fixed.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div>