Low cost microcontrollers rarely have good enough built-in timekeeping clocks/oscillators/peripherals to keep a system within a few hours after many months in the field. You often find comparisons of the clock drift for a given microcontroller. Discussion will be about how many parts per million accuracy the clock/oscillator has. 

The bottom line is that whether you use an internal clock, an external ceramic resonator or an external crystal, the accuracy is not going to work for this. For example, in Jeremy Cook's simple and clear explainer, a standard Arduino UNO would drift by up to 7 minutes per day. After a month we could be well out of the "few hours" I would have liked to keep within*. There is more to clock accuracy, and you can make some educated guesses to minimise the effect of drift if you keep track of temperature and maybe supply voltage but it won't improve the accuracy by the orders of magnitude I am looking for.

Even if those sources were accurate enough, there would not be an easy way to sync them to the time of day (waterproof enclosures, no buttons etc). That said, you could "prime" a technique like dayTime by ensuring that power was only applied within a certain window of  time within a day. That would seed the system with a "certainty head-start" but nothing that wouldn't be negligible after a day or few.

Just to quickly justify why GPS wasn't considered: unit cost and power budget. My devices often have to sleep for long periods, and I expect many of your dataloggers or sensor nodes have to do the same. This brings me to the conclusion of "What's the problem with microcontroller time-keeping?"; if you thought main clocks were poor time keepers after reading the above, wait until you see the specs for the low speed oscillators the sleep modes rely on...

* Please don't ask - I can't really say what the application was. Suffice to say that the project went ahead without dayTime built in and the idea has outlived the project which conceived it!