> On Time, and Why It's Hard

The epoch. Machines count seconds from January 1, 1970, 00:00:00 UTC, and everything since is an incrementing integer. ISO 8601 is the closest thing to a universal human-readable format for the same information - see Date Stamp Recon for the actual converter.

The Year 2038 Problem. A lot of systems store that Unix timestamp as a signed 32-bit integer. That format runs out of road on January 19, 2038, at 03:14:07 UTC - one second later, the count wraps back around to a large negative number, which most software reads as December 1901. Same failure mode as the Y2K panic, different root cause: Y2K was a storage-shortcut problem (two-digit years), this is an arithmetic-overflow problem (a fixed-width integer running out of bits). Most modern 64-bit systems already sidestepped it. Plenty of embedded and legacy 32-bit systems have not, and won't notice until they do.

Timezones ruin everything. They aren't clean hour-wide slices - India runs UTC+5:30, Nepal runs UTC+5:45, and some Pacific islands hop entire calendar days depending which side of the International Date Line their government prefers this decade. Add daylight saving time (which not every country observes, and which some countries have started and then abandoned more than once) and "what time is it in the other office" stops being arithmetic and starts being a lookup against a constantly-revised political database. This is also why Date Stamp Recon always shows UTC first and local time second - UTC doesn't change its mind.

Leap seconds. Earth's rotation is slowing down, almost imperceptibly, so every so often an official leap second gets inserted to keep clock time lined up with the actual planet. In 2012, a leap second exposed a bug in the Linux kernel's futex implementation that pushed CPU usage on affected servers to 100% - Reddit, Mozilla, and Yelp all had a bad night over one extra second. Several major tech companies now "smear" the leap second across an entire day of very slightly slower ticks instead of inserting it all at once, specifically so this doesn't happen again.

Why cron starts the week on Sunday. Cron's day-of-week field runs 0-6 with Sunday as 0, not Monday. It's inherited from POSIX C's struct tm, where tm_wday has always used the same 0-for-Sunday convention, which itself traces back to older US calendar conventions treating Sunday as the start of the week. Cron didn't invent the choice, it just never had a reason to break from the C standard library it was already built on top of.