www.virtualacorn.co.uk/forum

Several times over the past year or so the RISCOS real time clock has gone back in time by several years. It happened again yesterday. The machine was unattended and running a periodic check on the broadband router by injecting characters into the URI icon, waiting for the stats page to load, then appending the data to a file.
Bewteen 11pm and 1am the clock went back by four years (2004) leaving the month, day and time untouched. This is the typical symptom.
Checking the Windows clock (adjusted by NTP) it was fine. So something messed up the RISCOS clock. Since nothing else but Netsurf and Klikmacro were active it does not appear to be an application doing this.
Any ideas?

Make sure that the SyncClock module is running. This will sync the RISC OS clock to the PC clock every n seconds.
Do a *help SyncClock to make sure it's running.

SyncClock 0.10 (27 Feb 2002) is running and always has been. Somehow, the fact that the RISC OS year is wrong seems to escape its notice. The other day when the year went from 2008 to 2004 around midnight I only found out about 7am so obviously SyncClock didn't make any attempt to correct it. So it must be the realtime clock which gets corrupted, or SyncClock is not checking the year.

I just found another oddity. I've just had an alarm pop up (from !Alarm) "Meeting - An alarm was set for 11:30am Tuesday, 19th February 200" ... the time was around 09:20 !
I checked the alarm database and its definitely 11:30 today, and the system clock is showing the correct time (now around 09:45). What the heck is going on?
Err.. no it isn't because I just powered up the machine and the alarm was outstanding. Its today's alarm, and the machine has been powered up for weeks.
Investigating this kind of problem is difficult but its also worrying that it seems I can't rely on these things that I've relied on for many years. I don't know if its a VRPC problem or something else but I've never experienced this on any other Acorn/Castle machine.

This isn't a problem that rings a bell for me, so I would suggest that it's probably something specific to your setup. This could be something weird that's altering the date on the Windows side, or it could just be on the RISC OS side.
When the RISC OS date goes wonky does the Windows date also do the same? If not then "something" inside RISC OS must be causing it, I would hazard a guess that this is something that might have been added to the Boot sequence.
We can rule this out - install a new plain VRPC in another folder on the same machine - now see if that behaves the same. If not then it's something that's been added to the RISC OS boot sequence.
I am not sure of the relevance of the Acorn/Castle comment as neither of these companies ever produced a product like VirtualAcorn.

This clock problem (year going backwards by four years) has now occured on two of my VRPCs (one -SE the other -SA). It seems to happen at midnight as discovered by the fact that TempDir creates a new directory named from the date(e.g. 27Mar08) and the time stamp was 00:00:04 (it does an OS_Word 14,3 every 5 seconds to see if the date has changed).
The significant issue here is that SyncClock is running but it does not do its job completely. The day, month, hour, minute, second, are all correctly sync'd to Windows but the year suddenly becomes 2004 instead of 2008. The Windows time remains correct. Restarting SyncClock and changing its interval makes no difference.
I've now modified TempDir to monitor the year and when it goes backwards it raises an alert and resets it to the correct year. However, the next step is to monitor other running tasks to try to nail the culprit. It seems likely that its something that activates at midnight and converts the time to ordinals and back, otherwise there is no way that just the year could change leaving everything else untouched. So far the only task that I can see that does this and sets the clock is SyncClock itself.

It could be something running on either the RISC OS or Windows side that's doing it. If you remove SyncClock then the RISC OS time will not be synced and it will just count from the time VRPC is loaded.
So if the problem goes away without SyncClock then it's something on the Windows side causing it. If the problem persists, then it's something on the RISC OS side.

I've had a similar problem for a while. The clock jumps forward to 2011 and a weekly alarm in Organiser pops up. The windows clock remains correct, and a reboot fixes it. I think I have SyncClock running (the module is loaded).

Just to add, this is occasional, and is with VRPC-AdjustSA.

I've had another clock jump today. In 2007 it always jumped forward 4 years to 2011. Now it's jumping back 4 years to 2004.
This 4 year jump seems to be a common factor.
I spent ages trying to work out why I couldn't post to newsgroups and then spotted the clock. Time is correct in windows, and has remained correct since I corrected it.
Does SyncClock run by default? Is any information available on setting it up available?

SyncClock should be running by default. Do a *help SyncClock from the
command line.
It comes in two parts. The module is loaded first (Choices.Boot.PreDesk), then a config file sets up the parameters (Choices.Boot.Tasks).
If you move the two files out of the boot sequence and re-start then SyncClock won't be running.

Does SyncClock have a limit to how far out the clock can be? When the clock is close to what it should be it seems to stay in sync, but if its years out it never corrects it. I'm tempted to run a test to see just how far out it can be before SyncClock fails to adjust it, but maybe someone knows.
In recent months I've been running with SyncClock 15 and monitoring the year with a modification to TempDir. The year hasn't jumped, yet.
I've also doctored TempDir to stop it deleting empty directories, which it mormally does at midnight, or when its first run. Whether this is relevant may become known in time, but looking at everything that is running at midnight TempDir is the prime suspect. Are the other users who have seen the problem also running TempDir, or is this a red herring?

I've no idea what the limit is with SyncClock (assuming there even is a limit). It could be TempDir that's causing the problem, but I am not familiar with it myself.

Just for info Mike, we run TempDir v1.36 on multiple machines with RO 4.02/4.39 and have not seen any problems with TempDir and/or SyncClock.
HTH, Mike Nicholl
pp T.O.M.S.

The jump by four years is related to the cmos clock only storing the bottom 2 bits of the year. RISC OS stores the rest in cmos logical offsets 128/129 and manages it in software.
This still doesn't explain exactly why the date would jump. I guess it could be some interaction between syncclock and/or RISC OS and the cmos chip emulation. I've not looked at the syncclock sources so I'm not sure how much synching it is trying to do.