shouldn't this library set the system time, after an update() ?

[sercona]

I'm writing an app for a clock (of course..) and have been using this library for the last few weeks. I run my own ntp server (rasp pi on gps, so stratum 1, sort of) and I am logging all connections to it, so I can tell when the ESP (8266, for me) polls it.

I can set the update freq ok and it hits the server at those times. so far, so good.

but when looking at the update routine, it never SETS the system time! shouldn't it? I mean, what's the point of having ntp update your system if the local cmos clock (etc) is not updated?

at the very least, you should think about having a user callback be called when the update happens. that way, at least there's a hook I can vector off and call my own settime() routine. I realize that not everyone uses the same 'set system time' routine; some use hw clocks and some use the sw clock on the ESPs. but having a vector that the user-code can be triggered, when ntp update happens, that should be added, I would think.

additionally, it would be nice to be able to turn off auto-updates. usually, you'd send in a (0) for the arg, to tell the system not to do any more updates 'on cron' (so to speak).

[johnwargo]

What device are you running on? Most Arduino devices don't have a system clock. If you add an real-time clock (RTC) to it, you'll have one, but the software you need to write varies depending on the clock chip. I like your idea of the callback. I'm writing some code right now for a device that uses an RTC board along with the NCPClient - I'm just forcing the time check on my schedule then updating the RTC every time.

update: I didn't realize the ESP devices have a built-in RTC. Yeah, I guess if the client knew the device had an RTC (which, I think, it doesn't) then setting it automatically would be cool - but I don't think that's workable.

[sercona]

I mostly use a mix of esp-01s and esp-12 (wemos d1 mini). I do have esp32 modules but prefer to try using the lower end cheaper ones if I can, first (which usually works out fine).

the software clock works dandy if you have NTP keep it in sync. I'm a bit of a clock builder/fiend and have lots of my test builds littered all over the house, all NTP synced. to keep the ntp traffic local, I use a small cluster of rasp pi's that are GPS locked and thus local ntp stratum-1 servers. (I'm not a time-nut but I'm getting close, lol).

for my older builds, years ago, I loved using the ds3231 and you can still get little boards that are meant for rasp pi gpio headers and work great with their little supercaps.

but I find it hard to justify the board space and cost and i/o of having a 'good' clock like the ds3231 when sw clock plus ntp updates do the job really well. I watch how my off ntp is vs the various esp chips I have running clocks and they are to the second or better (wifi jitter not really being accounted for, yet).

even the atmel 'classic' (328) chips can run timelib.h sw clocks just fine. my current design approach is to have a dual setup where the clock 'engine' is a non-networked 328 or 32u4 chip and it handles whatever device and hw needed (led display, oled, nixies, servos for 'dayclocks', you name it). the link is simple serial between the ESP network-side controller and the device-specific atmel classic (usually) controller. it keeps things clean and the clock updates run on their own sw-clock (328 or 32u4) and get updates pushed to them over the serial from the ESP, which -does- have a regular chat with its local NTP server. if the network is down or I need to update the network cpu side, the atmel side still just keeps running, jitter free. its twice the cpus but I like this and its DIY so cost does not matter that much.

point is: on both those instances, the atmel runs a sw-clock and the esp runs a sw-clock. if left alone for days, it starts to drift way too much; but if you update once an hour, say, it stays accurate enough. more frequent updates will get you better short-term accuracy.

[sercona]

also, one could make a case that calls in timelib.h to 'setTime()' should do the right thing and if you have no hw-modules known to the system, there is always the sw-clock and that always works. if there is a hw-clock module, then there would be a method-over-ride (conceptually) where calls to setTime() would end up writing to the hw-clock, and the update mechanism that is also part of timelib can keep the rtc module updated from some source.

I guess it seems clear to me the best flow is to have something authoritative (like ntp) set a local 'reference' and any time you want to get time-of-day, you make calls to timelib and that fetches the sw-clock value, which is kept in sync by the hw-clock. and the 'authority' keeps the hw-clock in sync.

the examples I see online where they hit up the ntp server every second or even every minute - makes me shudder ;) poll the hell out of the local sw-clock; dont even overpoll the hw-clock. read that one lightly when you need to, but do your heavy polling on millis() or now() and never ntp calls or hw-clock reads. just my 2cents, fwiw ;)