System time behavior questions

We did some tests, and it seems that the firmware stores the system time in non-volatile memory from time to time. When rebooting, without network access, the system time still incremented monotonously from the time before the reboot. (which would be great!)

Is that correct?

What is the system time on a brand-new device that boots for the first time before it first connects to the network? (We can’t test that right now, have no brand-new devices left) Is it something close to 0L, or some arbitrary time like January 1st, 2010?

Also, is there some way to get a callback or such when system time is adjusted by the firmware, particularly if it makes a big jump?

(I’m asking because we are trying to integrate some measured values over time, and if we don’t understand the system time behavior, our integral will be completely off — e.g. we might have thought we integrated over 5min, but it was from 1970 or 2010 across a system time set to now.)

The STM32F2 devices have a built-in RTC that does that as long there is backup power available which can ge as low as 1.65V on VBAT.

The staring time is the UNIX epoch base time 1.1.1970.

I’m not aware of a callback, but if you are living in an area with DST you’ll have to cater for that too.

The time resync does happen once after a fresh cloud connect (full hanshake) and when your code calls Particle.syncTime() - so during your code execution it should not happen unexpected.

@jernstlun, the latest 0.6.1-rc.1 release candidate includes new Time API calls:


There may not be any documentation yet on these functions however since it is not an official release.

Particle.syncTimeDone() wouldn’t happen to return the delta time by which the clock was adjusted? That’d be great!

@jernstlun, Particle.syncTimeDone() only returns true or false:

Returns true if there is no syncTime() request currently pending or there is no active connection to Particle Cloud. Returns false when there is a pending syncTime() request.

@ScruffR, Starting with 0.6.1-rc.1 “starting” unitialized time is 2000/01/01 00:00:00.

@jernstlun, There is no function that returns the delta, but Particle.timeSyncedLast() can give you the timestamp received from the server during last synchronization and there is also a time_changed system event which should be fired when new time is applied to the RTC (either when setting time manually or when a synchronization occurs).


I’m obviously loosing track with the new features :weary:
I have to dive deeper in the latest releases then :sweat:


Apparently, when the system time is set, whatever sub-second counter that is being used to increment the time is not being reset. That is, the time may roll over to the next second anywhere from 1 to 1000 milliseconds later. Someone, like NtpTime that is trying to keep the system time close to the actual second is pretty much out of luck.

I know the system time resolution is only to a second, but for someone OCD about time like me, it would be nice if the second would “tick” close to the second.

Unfortunately it’s a hardware limitation. Unlike STM32F4 RTC peripheral [1], which provides subsecond resolution out of the box, as well as resets a subsecond counter when a new calendar time is written, STM32F2 [2] does not expose subsecond counter (prescaler) as a register and there is no way to reset it either (although I am not really sure that it does not reset it same as F4). Well, perhaps stopping/restarting the RTC peripheral completely might reset it, but it still sounds a bit useless, because the RTC setup time would still introduce ‘some’ latency.

The only viable option would be to have an external RTC IC if accurate subsecond calendar time is a requirement.




OK. It is easy enough to do in software, so I’ll skip the external RTC. Thanks for the response.
– Doug