Clock sync countdown timer

[aw-bib]

Currently, I could ask the clock to Update system time and it will raise an alert. I think it would improve usability to actually mimic a real time signal, especially to easily adjust an external watch (wrist watch or the like). The few pips IMHO help to get the groove 1, 2, 3, (4, 5) now, especially if you don't see the clock source.

[kylecorry31]

Thanks! I'll definitely add that

[Lee-Carre]

Website to compare your system's clock against UTC: Time.is. The comparison includes offset & measured network latency.

[aw-bib]

Website to compare your system's clock against UTC: Time.is. The comparison includes offset & measured network latency.

I may be wrong, but I assume that as long as my phone has Internet (then I have a lot of infrastructure around me ;) the ntp-services common on *nix-systems will just set the internal clock periodically, so no need to compare it manually against a time server. (And these ntp services will include the offsets etc.) But I'm no expert and just extrapolate from Linux to android.

However, mind that my above suggestion is that the existing clock tool of TS just learns to issue 3 to 5 beeps for the full minutes so you can set an external clock (read: backup/wrist watch etc.) against this time signal. I would suggest to style it to the GMT time signal from the BBC (linked above) as it is probably one of the best know ones on this small planet.

[kylecorry31]

@Lee-Carre the goal of the clock tool is for the user to fix their clock if they've changed system time while there is no internet, so I don't think I'm going to add the link to an external website (since if the user has internet, they would be able to just automatically update the time via system settings)

The other use case for the clock is being able to see seconds and UTC (for celestial navigation), and I'll likely have more additions (maybe a timer/stop watch)

[Lee-Carre]

Apologies, my terseness compromised clarity. I meant only to drop a pointer to something which may be of use.

I assume that as long as my phone has Internet … the ntp-services common on *nix-systems will just set the internal clock periodically, so no need to compare it manually against a time server. (And these ntp services will include the offsets etc.) But I'm no expert and just extrapolate from Linux to android.

Since I'm quite familiar with NTP, I'll elaborate somewhat.

To my knowledge, Android doesn't have an NTP client (not a proper one; at best a Simple NTP client which does indeed just hard-set the system clock). That's why one is published via F-Droid (intended for the GNSS receiver to get a fix quicker, especially from cold-start). On Android, the ‘automatic date & time’ feature (again, to my knowledge) gets somewhat-accurate time from the cellular network (though, the data it fetches wasn't intended for clock-syncing). Quite why it doesn't use NTP (at least over 802.11) or (better) GNSS, I have no idea. Not sure what happens on tablets without cellular connectivity.

NTP proper (ntpd) doesn't hard-reset the clock (which would be bad for servers, especially databases); it slews it gradually (changing the tick-rate (properly, the clock's frequency), if you will; 1ms per second kinda thing). It polls the servers it's configured with, regularly (though the interval is variable (& conditional)), and performs various analysis to determine what the average slew-rate should be and dynamically-adjusts it based on the statistical network measurements it makes (among other things, like detecting a false-ticking (or otherwise unreliable) server among several). This yields good accuracy (depending on network conditions); on the order of <100ms (I've regularly seen <10ms over a (fibre) WAN link, and <3ms over a LAN). The hardware clock is, I think, simply reset (to match system time) every so often (or, at least at shutdown). One cardinal rule of NTP proper is that time must never go backwards (think of timestamps in databases); if the clock is ahead, then it'll reduce the frequency until realtime catches up.

Simple NTP clients do as you describe, and blindly set the system time to immediately match that which they've computed (in a crude way) from whatever server it's pointed to. This is intended for situations when accuracy & consistency aren't too important, or you're resource-constrained (embedded devices, for example) which may include not having a hardware clock to keep rough time when powered off. Often used as the bare minimum to avoid massive offsets which cause problems. Accuracy is on the order of within-a-second (at the time; the clock will be allowed to drift afterward). Simple NTP will gladly make time go backward, regardless of how other software might react or feel about it.

Simple NTP is utterly useless without being able to reach a reliable server (over a non-terrible connection). NTP proper, however, once given chance to stabilise, will be able to continue disciplining the clock even if it loses all network connectivity. Adjustments come from the statistics it accumulates, and those statistics are updated when it can reach servers. It also stores data to disk, so that it can resume gracefully after a reboot, instead of starting from scratch. Almost like a watchdog to monitor the health of some important network service. Whereas Simple NTP is like (statelessly) querying an API. NTP proper runs persistently as a daemon. Simple NTP can be invoked from the command line, and terminates after its set the clock (or failed to reach the server).

Thus, you're right about being able to query NTPd about offset (and other metrics). Only NTPd, though, not Simple NTP clients.

NTPd is what's running on a host which is a time server for (other) clients. NTPd can also use many more sources (such as pulse-per-second from the likes of a suitable GNSS receiver, for sub-millisecond accuracy).

However, mind that my above suggestion is that the existing clock tool of TS just learns to issue 3 to 5 beeps for the full minutes so you can set an external clock (read: backup/wrist watch etc.) against this time signal. I would suggest to style it to the GMT time signal from the BBC (linked above) as it is probably one of the best know ones on this small planet.

Ah, that answers a question I had (that, no, this isn't a relevant issue for a clock-related thought I had). I'll open a separate issue.

Interesting idea. I've been in that situation, before. I do wish more clocks would include a receiver for getting time via dedicated signals (or GNSS). Good watches do.

the GMT time signal from the BBC

I thought they updated to use UTC? GMT (as a time standard, rather than a timezone) is (subtly) different (and that's a deeper rabbit hole than NTP, so I'll omit elaboration beyond pointing out that the difference is Earth-rotation time vs. atomic-time).

But, yes; the Beeb and their pips 😄. There's more charm with the speaking clock (at the third tone, the time will be …), I think.

Might a suggest giving this issue a less ambiguous title, then. To those familiar with the technicalities of horology, “time signals” means something quite different to the per-second pips.

I don't think I'm going to add the link to an external website

Indeed, that wasn't my intention.

More of a handy human-readable reference, which works anywhere. Useful to confirm accuracy, and such.

I didn't intend it to replace the clock feature (which, getting its time from GNSS, will be much more accurate).

[kylecorry31]

Notes: Consider using a countdown timer service / notification like the water boil timer here.