MiniTime v1.10 available

Hi All,

Version 1.10 of MiniTime is now available for download.

MiniTime was written as a replacement for SmallTime which does the same thing but doesn’t run on modern hardware and the licence doesn’t allow for altered versions to be distributed.

Like SmallTime, MiniTime displays the date/time in a small icon or window. In addition it provides a simple calendar. Time and calendar displays can be easily configured to suit one’s preferences.

Changes in this version are:

• Converted to a regular application (didn’t need any module stuff).
   
• Now uses BuildFJG and StrongLib to build, support for Track, etc.
   
• Added notification support. Just basic egg-timer functionality.
   
• Help button in colour scheme window didn’t work (missing code).
   
• When Schemes dialogue box opens, highlight the last chosen scheme.
   
• Only load (and use) Clipboard module if ClipboardHolder is absent.

MiniTime can be freely distributed under the 3-clause BSD licence, and comes with the source included. As always, all feedback is welcome.

Apologies for the diversion, but can you or anyone else point me at an app that will set the clock time/date from a network time-source, please? I could try hacking something that Rick wrote for me years ago that currently just corrects the hours/mins/sec so it also does the full date. But someone else probably has written something far better already! Just that I don’t know who/what/where…

Ummm….? NetTime?

Part of RISC OS. Run !Boot, go to Time And Date, and pick to set it from the network. That’s what the old Pi 1 does (it has no NVRAM or RTC).

point me at an app that will set the clock time/date from a network time-source

!Alarm.

If the date/time is set using !Alarm (or !Organizer) for about the last 10 years in RISC OS 5.19 or later, they simply invoke the RISC OS Configuration of Time & Date, the applications do not set it themselves. So it is simpler to just use RO Config to ‘Set Time from the Network’.

I just offered the alterative which has been available for the longest time.

I just offered the alterative which has been available for the longest time.

You missed Martin’s point: Alarm just fires up the Date & Time tool in Configure to set the time, so it’s not an alternative to using Configure.

The same is also true of Organizer, because neither it nor Alarm wasted time in re-inventing a wheel that the Configure plug-in had already solved.

I just offered the alterative which has been available for the longest time.

Except, the small detail that Alarm is a means of manually setting the time, FreeTime is an old utility to pickup SNTP time sources¹ from the internet and the obvious answer is, as both Martin and Rick and now Steve F. stated, NTP capability is in the OS.

Just look in Configure. The details of setup are in the PDF User Guide scroll down to page 107
I think the default is to use NTP.
UK users would be best advised to ensure that the pool targeted is UK.pool.ntp.org, for other countries, just check what the local time pool is – always target the pool and not an individual server.

¹ I believe the old SNTP time-servers are gradually being withdrawn, and the NTP servers tend to be pooled sets these days.

I just answered Jim’s question ….

can you or anyone else point me at an app that will set the clock time/date from a network time-source, please?

From page 391 of the User Guide, !Alarm is such an app.

From page 391 of the User Guide, !Alarm is such an app.

Page 107 of the same guide, to set up the time and date in the system configuration.
Page 391 pretty much says it starts the time and date setup plug-in…

which has been available for the longest time.

Alarm used to be the way to set the clock ¹, because it way predates the existence of a time and date configuration utility. But times change and Alarm doesn’t do what it used to do, it just hands over the the system setup.

¹ I used to set Sys$Time and Sys$Date in the command line as it was quicker than finding the disc with Alarm on it (I’m talking RISC OS 2 here), loading it, than faffing with the UI.

Interesting discussion.

For as long as I can remember, I’ve had Alarm running on the icon bar, displaying a full date and time. Alarm is configured to keep the machine synchronised to an NTP pool, and the machine has a RTC add-on so it wakes up knowing a time very close to reality.

This makes it easy for Alarm to keep in sync until shutdown.

IIRC there can be difficulties synchronising if the clock is too far out, as it will usually be if there’s no RTC present at switch-on. My choice was to just pay for the RTC add-on and have done with all the sync failures. But that may not be everyone’s choice.

Thanks, Rick! I’d totally missed (or forgotten) this!

Yes, works like the proverbial. :-)

What happened was that my ARMX6 stalled/froze at bootup a few days ago. Had the normal desktop visible, and the mouse moved the pointer. But no clicks or use of the keyboard seemed to do anything. Re-start got as far as a pre-desktop list of actions, then froze. Another re-start gave a black screen.

This has happened once before due to a connector coming loose. So I opened the box and gave all the connectors a shuggle. Then tried again. Machine now worked – seemingly as normal. Took me a while to notice that the clock only continued whilst the machine was on. Since it has a RTC with a battery I guessed the battry had finally failed. So decided it would make sense to get it to grab the time from the net rather than bother with a new battery…

Dave: Does that mean I should check when I first start the machine each day to ensure it got the time OK? Was fine this morning.

If it sometimes fails maybe the code should be altered to have it pop up an ‘alert’ on screen so the user doesn’t have to check.

Time is on my mind at present (sic) as I’m having to time-align audio files to the sample in order to do some analysis on the (poor) audio output from You Toob. Hi-Fi it ain’t!

If it sometimes fails

Not often, but it does. I have an Obey file as part of my dev setup that checks Sys$Year for sanity

Dave: Does that mean I should check when I first start the machine each day to ensure it got the time OK?

Unless it’s mission-critical, I’d normally expect to assume it works, and deal with the consequences on the odd occasion when it doesn’t.

Which, of course, is after you happen to notice that something is awry :-)

Dave: Does that mean I should check when I first start the machine each day to ensure it got the time OK?

Alternative answer. It depends on what setup you have, and what the consequences are to you of the time possibly being in error.

First thing to consider is whether you have an RTC. If you don’t, the time will be incorrect during boot-up, until the point at which NTP sync occurs. I believe that some files and/or some logs may be written during this time – those who know, please fill in here as it’s not a situation I’m familiar with.

You may also have to think about the consequences of inability to sync to NTP because your internet connection is down. The machine’s idea of time may be wrong for more than a couple of seconds during boot-up.

If these errors are important to you, ISTM that the only sensible course of action is to have an RTC. A working RTC, that is :-)

RTC batteries always give out eventually. Same goes for electronic key fobs, wireless door bell pushes…

You could, of course, set yourself an alarm reminder to buy a new battery before it craps out…

those who know, please fill in here as it’s not a situation I’m familiar with.

With no RTC whatsoever, the machine will boot thinking it is January 1970 (that’s what the Pi 1 does). A moment later, the time server is connected to and the clock is updated. I can see this happening as MiniTime is up the top right of the screen.

If I forget to plug the network cable in, it’ll stay set to January 1st 1970.

The RTC-with-failed-battery is an interesting case. My Pi 3, using the CJE module, fails to keep time but instead it seems frozen in time so if I turn it off on Tuesday morning and back on two days later, it’ll think it is Tuesday morning. NetTime is less useful here because it can take the Vonets longer to start up them RISC OS does, and if we’re coming up from a full power down the Livebox takes much longer (though it has a little UPS so can ride out power failures). In these cases, the network appears to be up as far as RISC OS is concerned, but the first connection fails, so NetTime goes to sleep.

RTC batteries always give out eventually.

Yup. I think the CJE is a standard CR2032 or something. But it means shutting down and then taking the machine apart. Kind of annoyed that I didn’t think to change the battery when moving the RTC from the 2 to the 3… but there you go.

It means the Harinezumi logs will have bogus dates, but if I get any remembered log at all then it means something went wrong, never mind when…

My Pi 3, using the CJE module, fails to keep time but instead it seems frozen in time so if I turn it off on Tuesday morning and back on two days later, it’ll think it is Tuesday morning.

That’s how my Pi 4 (without any RTC) behaves. IIRC it reads the timestamp of the CMOS file (which is re-saved every shutdown) so picks up where it left off, so to speak.

If the NTP request succeeds, the time is updated on the spot (I occasionally see this happening in real time, but on most occasions it’s already happened when the desktop appears). If the clock is showing (say) 23:15 instead of 07:30, that’s an indication that NTP has failed.

IIRC it reads the timestamp of the CMOS file

Strange. The Pi 1 has a CMOS file, and SDCMOS is active and changes are written to the file (there’s a pause as this happens), but settings are not being remembered.
Should it be loaded into memory before the OS, like on the Beagle? I have a vague recollection that this might be the case, but the help file with the ROM image just mentions creating the CMOS file so SDCMOS can start up.

Update: Thank you Google… https://www.riscosopen.org/wiki/documentation/show/CMOS%20RAM%20on%20the%20Raspberry%20Pi#TOC3

You may also have to think about the consequences of inability to sync to NTP because your internet connection is down. The machine’s idea of time may be wrong for more than a couple of seconds during boot-up.

It might for example be several years in the past. In that case file datestamps will be misleading, and things like mail fetching might duplicate old messages. Automated backup scheduling might kick in immediately, and find the existing backup is newer than some files, not copying them, and stamp the new backup as very old.

Update: Thank you Google

From which you have to ask yourself – “Is there a circumstance where the $.CMOS is needed when a $.!Boot.Loader.CMOS file exists?”
and if the answer is “No” then why not have line if Boot that deletes the former when the latter exists?

if the answer is “No” then why not have line if Boot that deletes the former when the latter exists?

It would make more sense to rejig SDCMOS so that it tried to access !Boot.Loader.CMOS first. Then the problem goes away altogether.

It would make more sense to rejig SDCMOS so that it tried to access !Boot.Loader.CMOS first. Then the problem goes away altogether.

True, but I’m not a programmer¹, I just spend my working days finding out what got messed up and producing workarounds to deal with the situation until they, maybe, fix the root cause.

I presume you’re suggesting that the two paths in this are order switched?

        ADR     r1, NonCanonicalisedPath
        BL      TryInit
        ADRVS   r1, NonCanonicalisedPath2
        BLVS    TryInit
        BVS     %FT90

¹ Maybe the occasional hack of what a more creative person made.

      [ :LNOT::DEF: StoreAtDiscAddress

NonCanonicalisedPath
        =       "SDFS:$.CMOS", 0
NonCanonicalisedPath2
        =       "SDFS:$.!Boot.Loader.CMOS", 0
        ALIGN

Yup, looks good. Just swap ’em around. Look for the one that is actually used first.

Yup, looks good. Just swap ’em around. Look for the one that is actually used first.

The idle part of my character says do this:

      [ :LNOT::DEF: StoreAtDiscAddress

NonCanonicalisedPath2
        =       "SDFS:$.CMOS", 0
NonCanonicalisedPath
        =       "SDFS:$.!Boot.Loader.CMOS", 0
        ALIGN

For absolute minimal effort :)

Good call.

While there’s no technical difference between moving the 2 there or in the code, if you were to do it in the code you’d be obliged to add a comment to say why it is being done back to front.

Doing it here? The reason ought to be obvious without the necessity of stating said obviousness.