We've been... "distracted" (I'll write more, later)
Yes -- leap seconds. They aren't particularly predictable. And, can make for unexpected results (e.g., when strftime returns a time having a seconds value of *60*, not "59"!)
The advantage of handling all the "magic" comes when YOUR local timebase loses sync with a time server -- so YOU know to insert the leap seconds.
In the case of my "complaining colleague" (at the top of the thread), it was his ignorance of all the subtle (but predictable) intracacies of "human time" that confused his expectations and computations.
I "solved" the problem by creating a "map to human time" function that takes a system time (an unsigned long int that is always monotonically increasing at a rate of 1 second per second) and provides the "human time" relative to that as offset by a tuple specifying some number of seconds, minutes, hours, days, weeks, months, years). Because the components of the tuple aren't constrained to represent "human times" (e.g., you can specify 37 months, 449 weeks, 82 days, -3 hours, 90045 minutes, -300 seconds), the possibility of specifying an incorrect
*time* goes away.It also makes it easy to find specific instants relative to some arbitrary epoch: START_OF_1900 (a system time) plus 23 years,
9 months, 2 weeks... and come up with a valid time representative of that instant. (Mapping back to system time from human time requires you specify a VALID human time -- so "March 43rd" throws an error. If you want to know when March 23rd is, then map "3 months, 43 days" using the aforementioned function!)