SparkTime vs Time library

Hi All,

Can anyone comment on the differences between @bko’s SparkTime library and the built in Time library?

I’m interested in something that will keep accurate time to a few seconds over the course of a day. They both seem to meet that requirement.

I’m also concerned about what happens when the Spark Core is offline. From the documentation it seems that the built in time library only updates the time when I tell it to. So I can obviously check for Spark.connected() == true before updating. However, its not clear what happens when the SparkTime library tries update its time when Spark.connected() == false. I know SparkTime updates via UDP. But are the UDP functions blocking or not? I couldn’t find that in the UDP documentation. I don’t want a clock that is blocking.

Does anyone have any thoughts?

thanks in advance.

Hi @matt_ri

The built-in Time functions update over the cloud and are, well, built-in so they have a some really nice advantages. Another advantage is that I ported the TimeAlarms library to work with the built-in Time functions.

I wrote the NTP library SparkTime before the built-in Time work was done and I think for most uses, the new built-in stuff replaces what I wrote. The advantages of SparkTime are are really in the achievable accuracy via NTP, daylight savings time handling for the US and Europe, and a lot of easy to use String methods. I have not tested it with the core offline, since that mode was not available when I wrote it, but you are in control over how often it tries to update and when the update fails, I think it just retries when you ask for the time. I would certainly update SparkTime if there was an issue.

So you should probably use the built-in Time library unless you have very special needs.

1 Like

During the recent outage I was playing with using @bko’s library for the NTP call and using that to set the time of the builtin in SparkTime.

rtc.begin(&UDPClient, “”);
rtc.setTimeZone(+11); // gmt offset

This allows me to have a time synced core without the connection to the SparkCloud and still use the builtin SparkTime.

I’m using the TimeAlarms library and that uses the builtin in SparkTime.

So I say use the best bit’s of both.


@bko Thanks for the quick reply. It’s unfortunate that your work wasn’t rolled into the core libraries. Thanks for all your work on this topic.

@mrOmatic That’s an interesting idea. Thanks!

1 Like


I hope this is the right place to ask this:

Im having a strange issue with the SparkTime library. It tells the time correctly only the first time and then it starts drifting and reporting a false time.
It only happens when I use this other function:

void loop() 

void random1(){             //this is to turn some NEOPIXEL LEDs using the NEOPIXEL library
    uint16_t i;
    uint16_t j;
    uint8_t r1=random(25);
    uint8_t g1=random(25);
    uint8_t b1=random(25);
    strip.setPixelColor(i,r1,g1,b1); i=random(180);
    strip.setPixelColor(i,r1,g1,b1); i=random(180);
    strip.setPixelColor(i,0,0,0); i=random(180); strip.setPixelColor(i,0,0,0);;
   // delay(1);

void gettime(){  currentTime =;  	
    if (currentTime != lastTime) {	
      byte sec = rtc.second(currentTime);
      if (sec == 10) {
	// Build Date String
	timeStr = "";
	timeStr += rtc.dayOfWeekString(currentTime);
	timeStr += ", ";
	timeStr += rtc.monthNameString(currentTime);
	timeStr += " "; 
	timeStr += rtc.dayString(currentTime);
	timeStr += ", ";
	timeStr += rtc.yearString(currentTime);
      } else if (sec == 40) {
	// Including current timezone
      } else if (sec == 50) {
	// UTC or Zulu time
      } else {
	// Just the time in 12 hour format
	timeStr = "";
	timeStr += rtc.hour12String(currentTime);
	timeStr += ":";
	timeStr += rtc.minuteString(currentTime);
	timeStr += ":";
	timeStr += rtc.secondString(currentTime);	
	timeStr += " ";	
	timeStr += rtc.AMPMString(currentTime);
      lastTime = currentTime;


Hi @plusmartin

I think the problem you are running into is due to some interaction with the Neopixel strip library. What exact library are you using here? If you can provide a bit more info, we can probably debug this. My SparkTime library depends the millisecond time provided by the system to be correct and I think it is likely not correct when you are using the Neopixel library.

Another option is to switch to the built-in time functions that are baked into the Particle firmware. You won’t get NTP accuracy but it will be good enough for almost everything.

Hi @bko

Thanks for your reply! I agree there must be some kind of interaction between the libraries but I cannot figure out which.
The libraries I am using are the NEOPIXEL and SPARKTIME available at the libraries.
I modified (simplified) the NEOPIXEL by deleting some stuff for unused models of LEDs.
The SparkTime is used as is, no modifications.

My idea is to build an LED wall-mounted clock, that tells the time with cool animations. This is why I want to keep it as precise as possible, maybe not to the millisecond but not more than say 5 seconds per day. The photon has no accurate real time clock (not sure how accurate) so I wanted to update the time every hour or so.

I hope you can help me find some relation between the libraries (I thought it was some variable but I dont know)


I’d think (but haven’t tested) the Photon RTC will stay within this 5sec several hours easily, but if you notice quicker deviation you can call Time.syncTime() more frequently.

AFAIK subsequent calls (maybe two within a few seconds every few hours) will even take the current cloud latency into account.

1 Like

So, this Time.syncTime() is another option to retrieve the time from the cloud? That is actually very interesting!
I wonder if it can tell me the local time so that I dont have to set timezone.
I will try to implement it, if you see a very simple example other than on the reference please let me know.

No, unfortunately Time.syncTime() only synchronizes to UTC and you still have to set the timezone yourself - but this usually doesn’t change that frequently :wink:
You could do this by just calculating your current zone with or without DST or retrieve the zone for your desired location some other way (e.g. location or IP lookup, or similar).