Working on a embedded Linux device built using yocto that is pulling a date via uart from another device with a satellite connection. By the time we have access to this date, we are well into a fully initialized multi-threaded application as well as various daemons running etc.

From what I have read, using stime() or settimeofday() can result in breaking anything relying on timers. I'm guessing that something like std::this_thread::sleep_for() would be included in this?

Is there a safe way to set the system time at this point or how do most embedded Linux devices that do not have internet access navigate this problem?

Working on a embedded Linux device built using yocto that is pulling a date via uart from another device with a satellite connection. By the time we have access to this date, we are well into a fully initialized multi-threaded application as well as various daemons running etc.

From what I have read, using stime() or settimeofday() can result in breaking anything relying on timers. I'm guessing that something like std::this_thread::sleep_for() would be included in this?

Is there a safe way to set the system time at this point or how do most embedded Linux devices that do not have internet access navigate this problem?

Edit: We do have an RTC but the implementation of hwclock we are using does not allow us to directly write to it, at least through the hwclock api. Here is the --help:

BusyBox v1.24.1 (2018-11-14 12:40:41 PST) multi-call binary. 
Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE]

And the link to the hwclock source.