Get the current date and time

Has anyone been able to get the current time from the network on a Raspberry Pi using RISC OS? In the Configuration Time and Date app with the option ‘Set from the network’ selected and a greyed out ntp2.demon.co.us appearing, the date and time is never changed after system startup. Pressing the Try button results in a ‘not connected’ message. This is for UTC-05 Eastern with DST active. The Raspberry Pi has an ArmV7 processor and the version of RISC OS is 5.28. Also, this Pi can connect to the internet using a wired connection and is able to surf the Web using DHCP.
I also have another newer Raspberry Pi that is running Raspbian that always is able to get the correct current date and time, even over a wireless connection.
It would be very inconvenient to have to manually enter the date and time with each use of the system, to say the least!

Update: Firstly, thank all of you who have responded to this question. The problem has been solved by:
(1) Finding by a web search a valid time server IP address, which for me turned out to be 129.6.15.28, which is time.a.g.dist.gov (The is for the Eastern U.S.)
(2) Overcoming the disabled (greyed out) option to enter a time server in the Time and Date application by editing an Obey file. This Obey file is accessed by double clicking on the Config desktop icon or clicking the middle button on the system icon at the bottom right hand corner of the screen and selecting Config, then clicking the Network icon, then the Internet icon. The obey file is located to the right of the Internet icon. The time server IP address is in this file. After saving the changes and rebooting the Raspberry Pi, the time will have been updated. Also, the greyed out IP address in the Time and Date application will also have been updated.

Appears to be working works here with Raspberry pi (compute module) in a Qube using default server pool.ntp.org
RISC OS 5.29

ntp2.demon.co.us

That’s not a valid domain. If it’s a typo, ntp2.demon.co.uk returns an error, and I suspect Vodafone has decommissioned all former demon services anyway.

Has anyone been able to get the current time from the network on a Raspberry Pi using RISC OS?

Yes, I use a local time server. The server itself sync with an external time server and then serves the time to all the local machines, to they are all perfectly syncronized. This includes all my Pis running RISC OS and also other boards running RO 5.

Make sure your time server is working and is actually delivering time.

If you have a Linux box, you can test your time server with:

# ntpstat

synchronised to NTP server (<your-time-server-ip>) ... 
   time correct to within 11 ms
   polling server every 1024 s

# echo $?
0

ntpstat provides the current situation and, to double check, immediately after type “echo $?” to get the ntpstat return status code, the number printed mean:

0, clock is synchronized
1, clock is not synchronized
2, clock state is unknown, for example if ntpd is not reachable

HTH

if you have a Linux box, you can test your time server with ntpstat

And if you do this on your Raspbian Pi which you say is syncing just fine, it will tell you which timeserver it is using. I’m willing to bet that it isn’t ntp2.demon.co.us (or even ntp2.demon.co.uk), because as James says, I’m fairly sure that it doesn’t exist any more.

You may need to sudo apt install ntpstat before the command will work, however.

In the Configuration Time and Date app with the option ‘Set from the network’ selected and a greyed out ntp2.demon.co.us appearing

If the NTP server name is greyed-out, untick the box “Pick a server automatically”. This should allow you to enter a valid NTP server (e.g. us.pool.ntp.org since you appear to be in the USA).

This is for UTC-05 Eastern with DST active.

Given that we’re in December, it would be odd to have DST currently active. Check that the box “Switch DST automatically” is ticked on the Time and Date settings.

I wonder whether this is a sign of an external problem? When I returned from holiday recently, my ARMX6 started up, then told me that the time was wrong. It showed 1st Jan 2100 00:00:00. I think this may be a sign of a failing battery.

However the problem showed up when I went into configure, already set to “choose automatically” and set to “pool.ntp.org”. It took 3 or 4 clicks of “try” before it set the time.

Two days later the same thing happened, except that no amount of clicks on “try” would set the time. In the end I powered off and rebooted, and it successfully synced.

Has something changed at ntp.org?

Has something changed at ntp.org?

Unlikely: pool.ntp.org supplies different servers in response to DNS queries, but individual servers may be having their own problems. In this case a fresh DNS query would produce a different list of servers to try.

What may be happening is that the first DNS query returns a “dud” server on the list, and RISC OS caches that response so won’t try another server until the entry times-out. One thing I do when that happens is to deliberately select a different NTP server (e.g. pool.ntp.org instead of uk.pool.ntp.org) and then click only on “Try”, never on “Set”. That gets me out of the short-term problem while keeping the “best” NTP server (uk.pool.ntp.org) as the configured server.

If the NTP server name is greyed-out, untick the box ‘Pick a server automatically’.

I cannot help with the OP’s problem, as I do not have a problem here, but …
My NTP Server name is faded, but correctly set to 10.0.0.1 as I have a NTP server on my router.
However, the ‘Pick a server from the network’ is selected … but also faded.
I have not discovered how to un-fade them, and hence I cannot change them even if I wanted to!
Perhaps they are faded if a local NTP server is found?

What may be happening is that the first DNS query returns a “dud” server on the list

It seems fairly common, I’d say about half the time I boot from cold I get the time not updating. What I have noted in this case is that the server is often an IP address, not a name.

It seems to me to be a fault of the pool (it shouldn’t be returning duds), but the RISC OS client ought to be able to spot a dud and retry.

As I’ve just booted when I see this, doing a reboot is my “fix”.

I’d say about half the time I boot from cold I get the time not updating … reboot is my “fix”.

This used to be me, too. But for about a year it seems to be working all the time. I’m running (relatively recent) 5.29 on ARMX6 and a Pi 4.

It seems to me to be a fault of the pool (it shouldn’t be returning duds), but the RISC OS client ought to be able to spot a dud and retry.

The NTP client should always resolve the name at time of use, as if it caches an IP address from the pool it may attempt to use a server which is overloaded or has been taken out of service.

Thanks to all who have responded to my question. I have updated my post with my working solution.