Clock setting won't stick

Running RPCEmu 0.8.11 and RO 5.21 on Win 7 Pro.

No matter how the clock is set, manual, or off the network, the correct time only remains for around 10 seconds then it reverts back to being an hour out.

If I switch DST off then it becomes 2 hours out.
I’ve tried everything I can think off, but it stubbornly will not set the correct time.
Doesn’t matter if Analog or Digital is set, it still jumps back 1 hour.

The Windows 7 clock is showing the correct time.

Any thoughts please?

Thanks
Dave

The Windows 7 clock is showing the correct time.

One of those windows system versus windows display items: if you look at the W7 settings it tells you it is "(UTC) Dublin, London… " or the next option up is “(UTC) Co-ordinated Universal Time” select the latter and now the Emulator and the W7 display agree.
Basically RPCEmu isn’t being fed the time + offset just the raw time, meanwhile RO assumes it can update the physical clock.
Perhaps RO should have a UTC+1 (BST) setting that it moved to for the daylight saving.

Doesn’t solve the problem Mr P.
If I do the change you suggest, then yes W7 and RO 5.21 can be reset to agree on time.
BUT.
Thereafter, no matter how set, all other RPCEmu and their versions of RO 4.02, 4.39 and 6.20 clocks are now an hour out, and will not sync again until I put back “(UTC) Dublin, London…”

It is a RO5.nn problem as all other version of RO work correctly.

Dave

Right to tackle this from another angle.

As the clock won’t stay fixed on the correct effing time, maybe something else installed is messin’ with it.
So…
The Windows clock is correct and matches every other computer, every other Virtual RO installed, every other clock, timer… in the house.

In ROOL RO …Boot Configuration Boot “Run at startup” tool (Being a crude interface) I’ve had to remove rather than just inactivate all the entries apart from three that remain.
Reporter
Zap
Alarm

I’ve switched Off the “Set from network” option and Set the clock time manually.
So for 10 seconds it shows the correct time, then it drop back an hour again.

What else is there?

Dave

I had the same problem when changing the Pi over to BST.

In the end I opened the ‘TimeSetup’ file that lives in
Boot.Tasks an added an extra line – Configure DST -

that seems to do the trick for now, must remember to delete
it when Summer Time ends. This is for RiscOs 5.21.(March)

At Wakefield Show I enquired at the ROOL stand and was told that that there was an error in the current copy of the
Configure Plug-in ‘Time and Date’ that means not all the
config details are saved to the CMOS (virtual on SD card)

At Wakefield Show I enquired at the ROOL stand and was told that that there was an error in the current copy of the Configure Plug-in ‘Time and Date’ that means not all the config details are saved to the CMOS

I think that question was to me in my desk-propping-up role helping out ROOL at Wakefield. Now I’m back at a computer I can be more specific: versions 0.04 and later of time setup should be fine, earlier versions definitely got muddled up.

However, the original poster here is about RPCEmu I think. There’s a fake podule called “SyncClock” in RPCEmu which may well be getting confused since it was written before RISC OS 5 gained auto DST functionality.

However, the original poster here is about RPCEmu I think. There’s a fake podule called “SyncClock” in RPCEmu which may well be getting confused since it was written before RISC OS 5 gained auto DST functionality.

Yup. Delete “SyncClock,ffa” from the RPCEmu\poduleroms directory and time is GMT with the RO DST setting OFF and GMT+1 with DST setting ON.

Not tested with base PC in other timezones, I will leave that to other people who are in said other zones.

Bryn,
Good thought, but unfortunately every time I correct and set the time, that line is excised from the “TimeSetup” file.

@ G D

As per my post – Sprows comment is valid. It works without the SyncClock beastie interfering.

Excellent catch Sprow and Steve,
Having deleted that file, the 5.21 clock show the correct and same time as every other clock.

However there is also an alt solution if you don’t want to delete the file…
SyncClock has one CLI command to switch it off

*SyncClock 0

If you put an Obey file in PreDesk containing that command, the clock thereafter remains synced.

Thanks for the assist guys, appreciated.

Dave

If you put an Obey file in PreDesk containing that command, the clock thereafter remains synced.

Which has the advantage of leaving things unchanged if you switch OS to one of the others. Nice one.

Apropos this little fake podule: If this exists in RPCEmu but not RPC then you could detect an RPCEmu instance by trying to run the star command. Must check upstairs on the real thing.

Interesting, on examination over an extended period deleting the “podule” seems to cause the emulator to not look at the system clock at all and the time then drifts badly. With the podule in place and sync set to 0 stuff seems to work.
SGP 0 – 1 GD

That is interesting, so for ‘wunce’ I’ve managed to get something right.
That’s spooky. ;-)

I wrote SyncClock because VRPC (and other emulators) were loosing in the order of seconds per minute, so every 10 seconds it re-synchronises time with the host PC’s clock (via the emulation of the CMOS clock). However, as mentioned something has changed in RISC OS 5.2X which means this correction is wrong. No one contacted me, so it hasn’t been fixed.