Time.now() not working properly

Troubleshooting
1

Hi I am using my electron in SEMI_AUTOMATIC Mode.
I run the following code after I connected to to cloud with Particle.connect();

if(Particle.connected()){
    String timeTest = "";
    timeTest += Time.now();
    Particle.publish("time",timeTest,PRIVATE);
}

But I dont get a correct UNIX timestamp. The timestamp I get looks like that: -2678354.

The docs say the time should be synchronized after the handshake with the cloud. So why am I not getting a correct timestamp ?
I would be really happy if somebody can point me to my probleme here :wink:

2

Try this

    Particle.process();  // allow for all the data to filter throug
    Particle.publish("time",Time.timeStr(),PRIVATE);

Time.now() does return an unsigned long so getting a negative number would suggest it’s rather an error in the String building than in Time.now().

3

I think the problem is that you’re trying to add an integer, Time.now(), to a String. I’m surprised that the compiler even lets you do this. You should use sprintf to create a string from the integer, rather than adding it to an empty String object.

char timeString[20];
sprintf(timeString, "%u", Time.now());
Particle.publish("time",timeString,PRIVATE);
4

@Ric, same here, you should use %u for unsigned.

And the operator+= for String objects does actually convert the number to a String amd concatenate the two String objects.

BTW @Gecko, the unsigned version of -2678354 would be 4292288942, might this be any better?

5

Ok. Changed %d to %u. Thanks for the info on the behavior of += with a String object. I try to stay away from Strings, so I wasn’t aware of that. I guess that explains why the compiler let him do that.

1 Like
6

Thank you for your help guys.
The code @ScruffR posted gives me: Mon Dec 1 00:12:38 1969
So I guess the time is still not synced :smiley:

Any ideas why the time is not synced ? since my code is inside Particle.connected() the handshake should successfully be performed?

7

I recall the time when people did employ their own wait loop to sync, but I thought that issue was cured a while ago.
What system version have you got?

The workaround was

  while(Time.year() <= 1970) Particle.process();

You could also try explicitly calling Particle.syncTime(), which you should do from time to time anyway, to correct RTC drift.

8

worked thank you!
I am using 0.6.0-rc.1 Pre-release

I will try that too. When you say from time to time. Is once every ~1h enough ?

9

Once a day is probably plenty.

2 Likes
11

Rather than start a new thread…

I am running 0.6.1 and I am putting a time stamp in the event data (there is a store and send function to ensure no loss events when cloud connection is out). I have noticed recently that some events have a timestamp 01-12-1999 01:00. I am doing a Particle.syncTime(); once every 24 hours and thought that the onboard clock would just provide the correct time even if the cloud connection is lost. I am getting the time/date with Time.now() to populate the event date/time. Any ideas what is going on here?

12

@armor, Particle.syncTime() is asynchronous and may not sync the time as fast as you need it. As such, you may want to use the (new) Time.isValid() function to check if a valid time has been acquired from the cloud. The onboard RTC will run as long as power to your device is not interrupted.

2 Likes
13

@peekay123

Thanks - good shout - just had a look at that and I see that Time.now() calls Time.isValid() so I guess it must be returning a false value. That explains why this has just recently started occurring (since 0.6.1)!

2 Likes
14

Hello, does the system properly maintain real-time between the instant Particle.syncTime() is called, and the instant the time response is received from the cloud and the RTC is updated? Just trying to determine if calls to Time.now() between these two events could ever result in some invalid time (ie 2000-1-1).

15

@am_sewi, did you read two posts above about Time.isValid()?

16

I did, but it’s not clear this explicitly covers the case where the clock was already valid before the sync. Based on the previous comments, my impression of the Particle.syncTime() behavior is this:

  1. Particle.syncTime() is called on a system whose RTC is already maintaining valid time.
  2. Subsequent calls to Time.isValid() will indicate false, and Time.now() will return some invalid time.
  3. Some finite time elapses (perhaps a while if network connectivity lost), time data is received from the server, and then…
  4. Subsequent calls to Time.isValid() will indicate truee, and Time.now() will return a valid time

If this behavior is correct, it seems counter-intuitive that an application cannot get valid time data from the firmware during step 2, even thought the RTC would still be maintaining valid time from the last time it was updated (prior to step 1). Let me know if I am misinterpreting the behavior.

Thanks!