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?
thanks…!
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?
thanks…!
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()
.
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.