Hello, in my Photon’s code I call Time.now() at the start of the setup function
The returned value often (I discovered it happens when the device is powered on after it hasn’t been
active for at least a couple of minutes. It never happens if I reset of flash the device) is 944006400 which is the timestamp for December 1, 1999 0:00:00
I already solved the issue by checking the given value and executing Particle.syncTime() if needed (with a waitUntil(Particle.syncTimeDone) and a waitFor(Time.isValid,10000) for good measures).
My only idea of what’s happening is that if the device is not connected to the Particle cloud for a given period of time and asks for the current time the cloud cannot provide fast enough the correct time and so provides an erroneous one (maybe -1 or something similar and 944006400 is actually hard coded in the Particle’s firmware), whilst instead if the device was already connected then the cloud is “ready” for the time request. I’m not sure, its the only explanation that comes to mind for such peculiar behavior (again if the device was online say one minute prior I can guarantee that if you power it up it’ll get the correct time right away).
I’ve successfully solved the issue so I’m not asking for help in that regard, what I’m asking is your opinion on the matter (what’s going on? why Particle’s cloud exhibits such a peculiar behavior?) and what most intrigues me is the actual erroneous date, December 1, 1999 0:00:00 , I would understand if the wrong date was the epoch starting time ( January 1, 1970 0:00:00 ) but it isn’t , so I’m curious, do you have any knowledge what this date actually means?
I don't think it's the cloud returning the erroneous date but rather when the device boots, it initializes the time variable to a default value. When you call synchTime() on the device, it may experience some network latency causing the time not to synch with the cloud at all. The Time.now() function leads back to RTC_GetCounter() which simply pulls the value from the STM chip. I get your point about the epoch default time of 1970 so I think you would have to take a look at the STM datasheet to see what the RTC register initializes to.
If you cold boot the device from powerdown, there is no time reference. Thus the device gets it from the first connection to the particle cloud. if you are in SEMI_AUTOMATIC / MANUAL mode, or running with SYSTEM_THREAD then at the beginning of setup from a power down state time will always be an invalid value. As you correctly identified, you can check if the time is valid.
Resetting or flashing device does not power-down the RTC, thus the time is still valid after bootup.
Testing for Time.isValid() should capture both the timestamp being 0 and the default/reset value of the RTC. It is OK IMO to use this before fetching the time with a call like Time.now();
Thanks @ninjatill awesome answer, yes It makes perfect sense that Time.now() say has a timer and if it can’t connect to Particle’s cloud fast enough then it uses its own default value as time reference.
Your answer really intrigued me and I did some digging into the stm32f10x_rtc.c link you shared, and other sources like the STM32F205RGY6 datasheet, but unfortunately cloud not find any clue on that specific value (I must admit I’m quite unfamiliar with datasheets and hardware-level components, maybe the value’s there but I just could not find it).
@justicefreed_amper Thanks for clearning up that resetting or flashing does not power-down the RTC, that partially explains the behavior, but I’d also like to mention that if I power the device down and then up a few second’s later (up to some minutes) the device’s still getting a valid time, does that mean that the RTC component still holds its value for a short period of time even if the device’s not receiving current anymore?