I discovered that time.now() is invalid for what appears to be an indeterminate length of time. Thus, initializing timers in setup() can lead to strange behavior. This problem was addressed for core and resolved by user hacks as checking for year > than 1970. Advising users that time is problematic in setup() in the reference might prevent wasted effort. My preferred solution would be to have an initialization state as done for connected. A user could be assured that the electron is fully initialized w/o having to know how the system is designed. Perhaps I misunderstand the level of users Particle sees as its market. (I did wait for Particle.connected true before using Time.now()).
1 Like
Thanks for reporting this - it makes sense. As part of connecting to the cloud, the system sends a request to update the current time, but it doesn’t wait for the response.
Let’s get this resolved in the next release! https://github.com/spark/firmware/issues/965
I’m happy; thanks. 
Quick response is always impressive and appreciated.
My debug is still in place and I just noticed a logical but unexpected related error - an early offset (zone) to convert Zulu to local time gets wiped out when( I suppose) the system sets up time.
Sorry to bother you especially because this might be redundant. I added related but unexpected error to my post via an edit. I though you would be notified. But , I’m not so sure now and want to make sure you see the relate time.zone problem.
I did see that and have update the issue description. 