The Problem with Time & Timezones - Computerphile

A 'leap smear' avoids leap-second disruptions by gradually adjusting clocks over a day so all servers stay internally synchronized, trading a small offset from true astronomical time for preserved event ordering and continuity.

Different authorities can create two local times in the same place because political or administrative decisions may cause adjacent populations to follow different clock rules, so geolocation alone can't determine local time.

Prefer well-maintained timezone libraries over rolling your own because they already encode the many historical, political and edge-case rules, sparing you constant maintenance and subtle bugs.

Storing Unix timestamps doesn't magically solve leap-second problems because UTC includes leap seconds while some astronomical time standards do not, so conversions and absolute-second reasoning can still produce inconsistencies.

Leap seconds break naive time implementations because occasional insertions like 23:59:60 create minutes with 61 seconds, and code that assumes 60-second minutes will either repeat a second or fall out of sync.

Calculating historical dates is nontrivial because countries adopted calendar reforms like the Gregorian switch at different times and sometimes skipped or shifted date ranges, so you need location- and era-specific rules rather than uniform arithmetic.

Short-notice government changes break deployed systems because pre-distributed timezone/DST data can't be pushed in time, leaving machines showing incorrect local times until they're patched.

Assuming uniform DST rules causes subtle mismatches because each region sets DST start and end dates independently, so neighboring users can be on different clock times for days or weeks.