robjharrison
Posts: 19
Joined: Tue Sep 05, 2017 6:48 am

Python .now() and ntp time wildly different in concurrent scripts?

Thu May 02, 2019 6:42 pm

I'm using the following to add a time stamp to a csv file against rows of sensor data collected at roughly 1Hz:
.append(datetime.now().replace(microsecond=0).isoformat(' '))

And the following at the same time (concurrently) to add a timestamp into some video footage:
import datetime as dt
start = dt.datetime.now()
timestamp = start.strftime("%y%m%d_%H_%M_%S")


This all works as expected. Except that i noticed today, how far out my times are between the two. As in HOURS out of sync
csv timestamp: 2019-05-01 22:29:46
video timestamp: 190502_09_56_16 (WOULD BE THE CORRECT TIME)

Is anyone able to explain why this might be/or potential fix ideas?



--
in case relevant. Before the device is run, it's connected via ethernet(only for enough time to pick up the date/time then removed as device is mobile from that point.), and the ntp service is stopped and restarted (within rc.local) to (in theory) allow the device to pick up the correct time and date. Id be fine if the sync wasnt precise, but this is no where even near expected. Examples above are running on the same device, started at the same time via bash, and are both otherwise working as expected. It seems as though only one script has picked up the new system/ntp time. Or am i wrong there? (pi zero W, Stretch, sensehat, ethernet)

epoch1970
Posts: 5448
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: Python .now() and ntp time wildly different in concurrent scripts?

Thu May 02, 2019 9:01 pm

now() gets the system date.
NTP can change/sync the system date.

If the above example is from 2 separate machines, one may be in sync with NTP and the other not.
Check the output of "timedatectl" to see if the system time is synchronized with an NTP clock or not on each host.

If the above is taken from the same machine, at the same time, something is wrong with the scripts.

/etc/rc.local is not the right way to do anything of importance in a machine that uses systemd (hence with Raspbian)
You can either use systemd's integrated NTP client (cf. timedatectl printout "systemd-timesyncd.service active") or install an NTP server like ntpd.
The ntpd server will sync the local clock also. Ntpd is cautious by default and may very well bail out rather than modify the system clock; this is often the case on Pi since it does not keep track of time when it is off.

systemd-timesyncd is built-in, it is client only so it doesn't have the same preventions as ntpd has. Prefer systemd-timesyncd if you don't need a server.

If even systemd-timesyncd does not work, your firewall blocks the NTP protocol. In this case you can install package htpdate, a faux ntpd that uses timestamps from HTTP servers to drive the local clock. Less accurate but good enough and should work virtually anywhere.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

robjharrison
Posts: 19
Joined: Tue Sep 05, 2017 6:48 am

Re: Python .now() and ntp time wildly different in concurrent scripts?

Fri May 03, 2019 11:09 pm

Thank you. Thats def useful.


The times in the original post are from the SAME device. But two different scripts.

script1
.append(datetime.now().replace(microsecond=0).isoformat(' '))

script2
start = dt.datetime.now()
timestamp = start.strftime("%y%m%d_%H_%M_%S")

when i removed the ntp service restart, the times both went back to being the same (even if both now incorrect). This would all bve so much easier if i could add a quartz clock module in combination with the sensehat. I did try a wittyPi but havent had it working yet (pi shuts down if i attemot to boot with both attached.

Return to “Beginners”