I saw this got pretty heated but I'm chiming in anyways. The original question was about making a clock. The simple fact is, the common resonator absolutely stinks for any reliable time reference over time. Furthermore, a simple MCU with a resonator makes for horrible accuracy. The drift alone is typically extremely noteworthy. And that completely ignores that the MCU only knows a relative time since last power up and not an absolute time reference.
This is why RTCs are so popular. Not only do they tend to have an absolute time reference, they tend to also be reasonably accurate (moreso than a simple resonator), take care of details like days, weeks, months, and especially leap years, and have extremely low power requirements to maintain time without external power. Even better, even cheap RTCs tend to have some form of modest calibration when installed according to their datasheet and more expensive units are both calibrated and actively compensated.
Frankly, creating anything other than the most simpletons of clocks without an RTC is highly questionable, unless its the trip than matters moreso than the destination.
I also read others talking about slamming time corrections from an external source. Be warned this also has some potential issues. If your application is dependent on alarms, relative time, and especially delays, its a great way to either miss them (if using poorly written software), potentially create alarm cascades (if using properly written software), or completely screw up fixed delays. Frequently, SNTP is what people incorrectly refer to when they mention NTP. There is a difference. A good implementation of time management which accommodates for drift will do so via tick interpolation over a finite period of time as well as rejection and error when skew is too large; typically based on accuracy requirements. So for example, if we have 100 ticks of error, it should be slowly interpolated over something like five seconds, minimizing the imposed error over those five seconds. Otherwise, simply slamming in 100 ticks over a 1 tick duration, may cause a cascade of alarms to fire, not to mention completely throw off all relative time measurements by 100 ticks (sleeping for 200 ticks just woke up 100 ticks short). And on real time systems, an alarm cascade can really screw things up royally.
Long story short, any clock should seriously consider even a modest RTC; especially when CPU clocking is a resonator. They have lots of advantages, especially where simple resonators are in use. I have created systems which managed clock skew and distributed time references (SNTP & NTP) for P25 digital radio systems. If you want to point at my low post count, I'll happily laugh in your face. Bluntly, proper time management is a surprisingly deep and complex subject with lots of subtleties waiting to whack the unprepared. Be extremely wary of anyone who attempts to trivialize time management, especially when their sole reference is a resonator. That's not to say CPU counters are without merit, but they can be deceptively alluring for the ignorant.