Difference between bko's SparkTimeAlarms & BulldogLowell's DailyTimerSpark

Does anyone know what the pros and cons are between these two libraries? I began looking into @bko’s because I need resolution to the second and I THINK @BulldogLowell’s is to the minute only?


Hi @daneboomer

My library is older and I think the built-in time functions are good if you are using the cloud.

NTP time (which my library uses) can be sub-one second accurate but most people don’t need that.

I would recommend using Time.now().

1 Like

Sorry, @bko, just so I’m not misunderstanding you, your library uses Time.now(), doesn’t it? Rather than NTP time? Unless there are two libraries on the go? Because as I understand it your library knows what time it is by “setting the clock” with this
#define now() (Time.now()+time_zone_cache)
bit of code from line 14 of timealarms.h?

Hi @daneboomer

Sorry for the confusion-I misread your title. My time keeping library SparkTime predates the system Time code and does its own thing. It does use NTP to contact a server and get a reference time and then keeps track of the offset from that in milliseconds.

Time alarms (SparkTimeAlarms) is different library that is a port of an alarm-clock like library that does use system time. I just ported it, I didn’t write it. It requires you to “service” the alarm clock periodically by calling one of its functions, typically a special version of delay() that checks to see if the alarm should fire. Lots of people like it because it has a lot of flexibility.

Thanks @bko!

So long as SparkTimeAlarms isn’t blocking with its special version of delay…I think I like it too…

You can call it with a zero delay to get non-blocking behavior (well, it is minimum overhead anyway). When you call TimeAlarm.delay(0); it will at some point call your alarm function and be blocking until that returns.