> On 2020-09-15, at 2:07 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 
> 
> So why don't we
> - modify the VM to stamp events with the utc second clock, 

The one possible problem I can foresee is if any OS event stuff we try to talk to expects timestamps consistent with its own view; imagine getting some event that needs to be replied to with everything the same except for one field updated etc. If we've stuck our own timestamp in then it could bollix things up. No idea if such events actually exist outside the realm of ancient, faintly remembered, RISC OS cases.

*IF* this seems to have any plausibility, then we could stick with using the OS timestamp for the incoming events, but derive our prim 135 tick value from

a) catching the first event, reading its timestamp, deriving an offset from our uSec tick, saving that and then doing the math anytime someone wants a prim 135 value, or

b) finding out which OS time api is being used by the OS to stamp events; it really should be documented. Of course, we have plenty of experience of OS doc being... imprecise.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: PIC: Permute Instruction Codes