Date/Time problems during Boot

I have an Organizer user with a PandaBoard ES which does not have a battery-backed clock, and gets the date/time from the internet.

After a recent update from RO5.21 to 5.22, when Organizer was started at boot it had problems. We have tracked these down to an incorrect machine date/time.

Organizer v2.23 has a check at startup that the current machine date/time is less than one year from the date when Organizer last wrote the OrgData file, but this check did not initially fail.

After investigation, it appears that for about 9 seconds after the start of !Boot.!Run the date/time is incorrect, as it starts at 2/1/1970 00:01:00.
I suspect that sometimes the date/time may be within 1 year (because Organizer sometimes does not find a bad date), but I have been unable to prove this yet.

The boot sequence ends after about 12 seconds, so for about 75% of the boot sequence the time and date are incorrect.

If Organizer happens to start before the clock is corrected, then it causes obvious visible problems. But anything else starting when the clock is totally wrong could also have problems, if they use the date/time in any way (eg writing a timestamped file). These problems may be not so obvious!

It appears that the exact point when the date/time are corrected can vary by a little, which can cause variations in the problems seen: one recent test the clock was corrected just 0.3 seconds before Organizer started, so it started without any problems.

There was a similar thread Time… raised, but it seemed to be more about non-uk use of RPCemu. Also thread Early Internet?. Either may be related.

All this sounds wrong and potentially dangerous to me.

- Can it affect all machines without a battery-backed clock?

- Presumably the clock is corrected by the NetTime module in the background sometime during boot, whenever the NTP server responds?

- Can anything be done to reduce the chance of applications starting with an incorrect date/time?

I have an ARMiniX which does I think include a real-time-clock. If your machine lacks one then I assume its starting up with a default “time zero” and relies on NetTime being run during bootup to find out the actual time.

So far as I know, its quite possible for either its attempt to fail, or vary in how long is required.

Where in your bootup sequence is NetTime called? Maybe you could ensure it is early, and then have a following program that stalls the bootup until it reads a ‘non zero’ time and can tell the clock has been set.

FWIW I avoid NetTime for other reasons, but have the RTC. I’m not sure but I think you can buy the RTC addon. If so, I’d recommend one for obvious reasons.

Jim

Not a full solution, but could whatever obtains the date and time set a variable to say ‘Read’?
Any program that needs a correct time would then know to wait and try again?

I also think it would be good for the OS to report¹ ‘Date and time unset’ if it can’t read from an RTC or time server.

Not a full solution, but could whatever obtains the date and time set a variable to say ‘Read’? Any program that needs a correct time would then know to wait and try again?

I did change Organizer to try and detect this problem, by checking that the current time was within a year of the time last known to Organizer. If not it gives the options to Continue, Set Time, or Quit.

However…
1. The check did not fail in the case reported to me, for reasons I do not understand.
2. Surely applications should not each have to do a check like this?

My boot checks that the year is >2014 and aborts if it isn’t.

Surely applications should not each have to do a check like this?

No, they shouldn’t. But I don’t think there’s been any solid suggestion of an alternative as yet.

Maybe your “Continue, Set Time, or Quit” could be made into a standalone program to go in the startup so this only needs to be done once for everything?

I did change Organizer to try and detect this problem, by checking that the current time was within a year of the time last known to Organizer.

Perhaps time to mention again my simple Obey file in Tasks called !CheckYear, which I edit each New Year, and which has the single line:

If Sys$Year<“2015” Then Error 0 This machine has been reset! Please set the year to the current year and then re-boot!!

This detects an accidental reset and the year being less than current

It would seem simple to devise a system which saved the current time on shutdown and made a comparison with this at next boot time to ensure it’s later. It doesn’t even have to be human-readable.
Of course, scheduling difficulties for m/cs without a real time clock like this RPi would need addressing.

But it’s a system-wide problem, and there should, IMHO, be a system solution.

Curiously, my “Reset” detection file is only activated when I change the ROM image – but is this because the time is stored in with the ROM image on the RPi, and then restored to CMOS sometime during boot-up?

Apologies for the rambling nature of my posting!

It would seem simple to devise a system which saved the current time on shutdown and made a comparison with this at next boot time to ensure it’s later. It doesn’t even have to be human-readable.

I recall this was done at some point: when the machine started up it would set the time to the ‘last shutdown’ time (rather than 1970) before checking nettime and/or real time clock so that this was avoided.

Can anyone remember why this change was reverted please?