the time goes forward 5 minutes each week

Thinking about that, I wonder whether something could be added to https://banglejs.com/apps/?id=widadjust to allow it to figure out the drift using GPS.

It would be pretty nice if it had some means of measuring its own drift. Years ago I wrote my own clock drift corrector for a HP 50g graphing calculator, though instead of using GPS it was just based on my periodically entering the correct date and time and manually pressing a button right on the second, at which point it would calculate the corresponding drift. Just a couple of iterations of this quickly made it more accurate than a $50 quartz Timex watch. :)

If there was a way for the app to receive an event when connecting to the App Loader and updating the date/time, it could then compare the new value to the current clock along with the last known date/time of adjustment in order to determine the drift itself.

If there was a way for the app to receive an event when connecting to the App Loader and updating the date/time, it could then compare the new value to the current clock

That's a neat idea putting it in the App Loader, it'd just require writing a file after we set the time. The only issue is that watch reboots between App Loader runs would knock out the timings, and so if it was automatic it's possible it could end up configuring the PPM difference wrong.

Thinking about how the timekeeping broke in 2v22 made me realise it wouldn't be the end of the world to actually add an optional adjustment inside the Bangle.js firmware (in the jshGetSystemTime function) so I guess that could be an option to make it even more seamless...

That's a neat idea putting it in the App Loader, it'd just require writing a file after we set the time. The only issue is that watch reboots between App Loader runs would knock out the timings, and so if it was automatic it's possible it could end up configuring the PPM difference wrong.

I thought about that. Maybe a sanity check could be performed that makes sure the watch's reported time isn't too far off from actual time, and if it is, the recalculation of the drift could be skipped for that occasion (perhaps with a warning message printed on the console, if desired). Or else have a way to just let the user manually request when the drift should be calculated and the time be adjusted, perhaps.