The Problem with Time & Timezones - Computerphile

The Problem with Time & Timezones - Computerphile — Computerphile

Computerphile

AI-assisted summary of The Problem with Time & Timezones - Computerphile — original source. Check the original for full context.

Source published:

Key ideas

  • Writing custom time-handling logic is notoriously error-prone due to compounding edge cases, including fractional hour offsets, diverging Daylight Saving Time schedules, and geopolitical calendar shifts. (0:00)
  • Geopolitical anomalies can instantly break software assumptions: Samoa excised an entire day (December 30, 2011) to cross the International Date Line, and overlapping populations in the West Bank observe different time zones within the same coordinates. (2:50)
  • Fluctuations in Earth's rotation necessitate leap seconds (23:59:60), which can crash or desynchronize naive software systems expecting strictly 60-second minutes. (6:41)
  • Google mitigates leap second synchronization failures using a 'leap smear' technique, dilating clock ticks by microseconds across a 24-hour window to prioritize monotonic continuity over absolute solar precision. (9:16)

Detailed notes

## Background Published by Computerphile on YouTube on December 30, 2013, this video features Tom Scott exploring the deceptively difficult task of building a web application that tracks elapsed time. The video description humorously poses how hard calculating elapsed seconds can be, framing time as something that twists and turns unpredictably and is certainly not to be trifled with.

## TL;DR Tom Scott illustrates the hidden complexity of date and time handling through the narrative of a developer building a seemingly simple web calculator. As the application encounters fractional time zones, conflicting Daylight Saving schedules, skipped calendar days like Samoa's date-line jump, and historic calendar transitions, simple arithmetic breaks down into chaotic edge cases. Celestial mechanics further complicate matters with unpredictable leap seconds, forcing modern infrastructure like Google to implement workarounds such as leap smears. Ultimately, Scott delivers a passionate warning to engineers: never attempt to write your own time-handling code, and instead rely entirely on established, battle-tested open-source libraries.

## Atmosphere & style The presentation carries the frantic, darkly comedic energy of a seasoned developer recounting a past trauma. Tom Scott speaks with rapid-fire delivery, expressive disbelief, and escalating exasperation, transforming dry computer science concepts into an engaging cautionary tale. Watching it feels like a descent down an inescapable rabbit hole of edge cases, shifting from cheerful overconfidence at the outset to total, humorous surrender by the conclusion.

## Bulletin - [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) Writing custom time-handling logic is notoriously error-prone due to compounding edge cases, including fractional hour offsets, diverging Daylight Saving Time schedules, and geopolitical calendar shifts. - [02:50](https://www.youtube.com/watch?v=-5wpm-gesOY&t=170s) Geopolitical anomalies can instantly break software assumptions: Samoa excised an entire day (December 30, 2011) to cross the International Date Line, and overlapping populations in the West Bank observe different time zones within the same coordinates. - [06:41](https://www.youtube.com/watch?v=-5wpm-gesOY&t=401s) Fluctuations in Earth's rotation necessitate leap seconds (23:59:60), which can crash or desynchronize naive software systems expecting strictly 60-second minutes. - [09:16](https://www.youtube.com/watch?v=-5wpm-gesOY&t=556s) Google mitigates leap second synchronization failures using a 'leap smear' technique, dilating clock ticks by microseconds across a 24-hour window to prioritize monotonic continuity over absolute solar precision.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) Developers should never attempt to implement custom time zone calculations from scratch. - [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) Time zone offsets do not strictly adhere to integer hour increments, as demonstrated by South Australia's 9.5-hour and Nepal's 5.75-hour offsets. - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) Daylight Saving Time rules vary widely across jurisdictions, with countries switching on different weekends rather than globally synchronized dates. - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) Opposite hemispheres invert seasonal clock changes, causing Southern Hemisphere clocks to advance for spring while Northern Hemisphere clocks move backward in autumn. - [02:50](https://www.youtube.com/watch?v=-5wpm-gesOY&t=170s) Geopolitical decisions can eliminate calendar dates, such as Samoa skipping December 30, 2011, to align trade with Australia and New Zealand. - [02:50](https://www.youtube.com/watch?v=-5wpm-gesOY&t=170s) Short-notice governmental decrees, like Libya's 2013 clock change cancellation with two days' notice, leave software maintainers unable to distribute patches in time. - [02:50](https://www.youtube.com/watch?v=-5wpm-gesOY&t=170s) Geographic coordinates alone cannot determine local time, as seen in the West Bank where Israeli and Palestinian populations follow separate time zones in the same territory. - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) Historical calendar transitions from the Julian to Gregorian calendar omitted blocks of days at differing times across countries, ranging from 1752 in Britain to post-1917 in Russia. - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) Historical English civil years began on March 25th (Lady Day) rather than January 1st, meaning January and February belonged to the prior numerical year. - [06:41](https://www.youtube.com/watch?v=-5wpm-gesOY&t=401s) Earth's irregular rotational speed caused by tectonic and atmospheric dynamics forces the periodic introduction of leap seconds creating a 23:59:60 timestamp. - [06:41](https://www.youtube.com/watch?v=-5wpm-gesOY&t=401s) Standard Unix epoch timestamps fail to fully abstract away astronomical discrepancies between UTC civil time and atomic time scales. - [06:41](https://www.youtube.com/watch?v=-5wpm-gesOY&t=401s) The only reliable engineering practice for handling time is using established, community-maintained open-source time libraries. - [09:16](https://www.youtube.com/watch?v=-5wpm-gesOY&t=556s) Google's 'leap smear' resolves distributed database race conditions by spreading the extra leap second across 24 hours in fractional microsecond adjustments. - [09:16](https://www.youtube.com/watch?v=-5wpm-gesOY&t=556s) For distributed transactional systems, maintaining monotonic sequence continuity is fundamentally more important than absolute solar accuracy.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) The Naive Time Calculator and Fractional Offsets

Every software developer eventually runs into the challenge of handling time, but Tom Scott cautions that he cannot provide an easy solution—only a cautionary tale. He frames the scenario through a hypothetical developer building an apparently trivial web application: a tool that takes a user-supplied date and time and calculates how many seconds in the past that event occurred. Initially, the application seems straightforward, but the developer decides to enhance it by adding a drop-down menu allowing users to select an hour offset ahead of or behind Greenwich Mean Time, making it possible to compare the current time in New York with five days prior in London. The developer believes the problem is solved cleanly with simple integer offsets.

```mermaid flowchart TD accTitle: Escalation of Time Tracking Edge Cases accDescr: Flowchart showing how simple time calculations break down as edge cases accumulate from offsets to astronomical shifts. subgraph Basic["Basic Variations"] A["Integer Hour Offsets"] --> B["Fractional Offsets<br>(Australia, Nepal)"] B --> C["Daylight Saving Shifts<br>(Opposite Hemispheres)"] end subgraph GeoPolitical["Political & Historical Shifts"] C --> D["Date Line Skips & Border Overlaps<br>(Samoa, West Bank)"] D --> E["Calendar Reforms & New Year Shifts<br>(Julian/Gregorian, March 25)"] end subgraph Astronomical["Astronomical Anomaly"] E --> F["Leap Seconds<br>(23:59:60)"] end ```

The system quickly unravels as international users begin reporting problems. A user from Australia reaches out to inform the developer that their local time is offset from Greenwich by 9½ hours, forcing the programmer to implement a bespoke exception. Shortly thereafter, an inquiry arrives from Nepal, where local time sits at 5¼ hours ahead of Greenwich. After patching in yet another special case, the developer consults what is supposed to be the canonical database of international time zones to ensure every global region is represented, assuming the problem has finally been laid to rest.

- Tom Scott’s direct warning to developers: “I can tell you why you really should never, ever deal with time zones if you can help it.” - Initial assumption: Time zones differ by whole, predictable one-hour increments relative to Greenwich. - Fractional offsets encountered: South Australia / Northern Territory (9 hours 30 minutes) and Nepal (5 hours 45 minutes).

[01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) Daylight Saving Time and Geographic Inversions

The fragile offset logic collapses completely with the arrival of autumn. A user from England contacts the developer to report that all calculations are off by precisely one hour. The programmer defends the code, arguing that Daylight Saving Time (DST) changes were already recorded and accounted for based on their own local calendar rules. The English user points out the fatal flaw: different countries adjust their clocks on entirely different weekends, with the United Kingdom shifting its clocks an entire week earlier than the developer's home region.

Confronted with the realization that DST rules vary by nation, the developer pulls down a transition table to programmatically track individual national switch dates. Any relief is short-lived. A user from the Southern Hemisphere calls to explain that their clocks do not move backward in autumn during the developer's season; instead, their spring arrives in November, requiring clocks to spring forward while the Northern Hemisphere falls back. At this point, the developer is left staring longingly at a bottle, realizing their once-simple program is rapidly turning into an unmanageable thicket of branch logic.

- England's correction to the developer's naive DST implementation: “We shift our clocks back a week before you do.” - Hemispheric inversion: While Northern Hemisphere countries set clocks back in autumn, Southern Hemisphere countries advance their clocks during their spring in November.

[02:50](https://www.youtube.com/watch?v=-5wpm-gesOY&t=170s) Political Realities, Skipped Days, and Borders

The edge cases escalate from cyclical schedule adjustments to geopolitical decisions that erase entire calendar days. Samoa provides a dramatic example: situated in the Pacific right near the International Date Line, the nation decided in late 2011 to align its commerce with its major trading partners in Australia and New Zealand. To do so, Samoa jumped from December 29, 2011, directly to December 31, 2011, completely skipping December 30 and shifting from twenty-four hours behind to hours ahead of Greenwich. Historical anomalies further complicate matters: during World War II, the United Kingdom adopted British Double Summer Time, running two hours ahead of Greenwich despite Greenwich being located within its own borders.

Tom admits that his storytelling mirrors his own agonizing past experiences with programming time systems. National time alterations occur far more frequently than programmers expect, often shifting multiple times within a single year due to changes in government. In late 2013, the Libyan government announced with only a couple of days' notice that it would abandon its planned clock change, leaving software vendors with zero time to distribute an operating system patch and throwing every computer in Libya an hour out of sync. Geopolitical conflict produces even stranger anomalies: in the West Bank, Israeli and Palestinian populations living in the exact same physical territory observe different time zones concurrently based on their governing authorities, making it mathematically impossible to determine the correct time from geographic coordinates alone.

- Tom Scott reflecting on his own developer trauma: “Because I've done this before and it's really, really frustrating.” - The West Bank spatial conflict: “Now you have two populations of people in the same location who are following different time zones.” - Samoa's border jump: Completely eliminated December 30, 2011, going straight from December 29 to December 31. - British Double Summer Time (BDST): Kept the UK two hours ahead of Greenwich during WWII. - Libya (2013): Canceled daylight saving changes on two days' notice, desynchronizing all operating systems nationwide.

[05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) Historical Calendar Shifts and New Year Anomalies

Just as modern political quirks are patched into the code, historical researchers introduce a whole new layer of temporal chaos. A historian attempting to calculate intervals dating back to the 18th century requests support for the transition between the Julian and Gregorian calendars. The switch did not involve lost time in an absolute sense, but rather a direct calendar skip where a block of days was excised overnight to realign with the solar year. The programmer adds the calendar tables, creating a fragile spaghetti codebase, only to receive a call from a Russian historian pointing out that Russia did not adopt the Gregorian calendar until after the 1917 revolution in the 20th century—and that the specific dates omitted vary based on jurisdiction.

The timeline fractures even further when British historical conventions are factored in. Prior to the mid-18th century calendar reforms, the English legal and civil year did not commence on January 1st; it began on Lady Day, March 25th. Under this system, March 24, 924, was immediately followed on the next day by March 25, 925. Conversely, December 31, 924, transitioned into January 1, 924, because the calendar year continued running until late March. Attempting to parse historic dates sequentially without knowing the specific local convention yields completely invalid math.

- Tom Scott highlighting the chronological disorientation of early English calendars: “Just to blow your mind there.” - Julian-to-Gregorian transition: Countries skipped blocks of days at different points in history (e.g., Britain in 1752, Russia in the early 20th century). - Historic English New Year: Prior to adoption of January 1, the official year turned over on March 25th (Lady Day), causing January and February to share the numeric year of the preceding autumn.

[06:41](https://www.youtube.com/watch?v=-5wpm-gesOY&t=401s) Leap Seconds and Astronomical Discrepancies

The ultimate disruption comes from celestial mechanics. An astrophysicist informs the programmer of an impending leap second, caused by the fact that the Earth does not rotate at a constant velocity. Tectonic plate movements, shifting core dynamics, and atmospheric friction cause planetary rotation to fluctuate unpredictably. To keep solar time aligned with civil time, the International Astronomical Union and international timekeepers periodically mandate the insertion of an extra second. Instead of rolling over smoothly from 23:59:59 to 00:00:00, standard clocks display the anomalous timestamp 23:59:60, creating a 61-second minute that crashes naive software expecting minutes to strictly comprise 60 seconds.

```mermaid flowchart LR accTitle: Leap Second Handling Discrepancy accDescr: Diagram illustrating how UTC handles leap seconds via an extra second compared to a hard repeat or astronomical time. subgraph UTC_Standard["Standard UTC Rollover"] U1["23:59:58"] --> U2["23:59:59"] U2 --> U3["23:59:60 (Leap Second)"] U3 --> U4["00:00:00"] end subgraph Flawed_Systems["Crash / Desync Risk"] F1["Repeats Second<br>(23:59:59 twice)"] F2["Drifts 1s Out of Sync"] end U3 -.->|"Poor Handling"| Flawed_Systems ```

Developers often assume that using a standard Unix timestamp—counting the continuous elapsed seconds since the epoch of January 1, 1970—eliminates this headache, but it fails to solve the underlying problem. Coordinated Universal Time (UTC) incorporates leap seconds and requires dealing with non-standard timestamps, while purely astronomical and atomic time scales omit leap seconds and steadily diverge from civil clock time so that astronomers can aim telescopes accurately. Tom emphasizes that the only sane path for a software engineer is complete surrender: abandon the hubris of writing custom date-time logic, rely exclusively on heavily vetted, open-source time libraries built by previous generations of engineers, and never inspect the underlying code again.

- Tom Scott’s absolute rule for date-time programming: “You look at the people who have dealt with this before, the people who have built the spaghetti code, and you thank them very much for making it open source, and you give them credit, and you take what they have made and you put it in your program, and you never ever look at it again.” - Astronomical cause: Irregular terrestrial rotation driven by mantle movements, tectonic drift, and internal dynamics. - The leap second artifact: The clock reads `23:59:60` before advancing to `00:00:00`. - Software failure modes: Applications either crash, freeze, repeat a second, or fall permanently out of synchronization.

[09:16](https://www.youtube.com/watch?v=-5wpm-gesOY&t=556s) Google's Leap Smear: Continuity over Strict Accuracy

For massive distributed systems handling millions of financial or database transactions every second, the sudden addition of a 61st second or repeating an existing second can cause critical race conditions and data corruption. If two events are recorded with identical timestamps or out of chronological sequence, distributed databases cannot reliably determine causality. To solve this, Google developed an infrastructure technique known as the "leap smear."

Instead of halting the system clock or introducing a sudden 23:59:60 timestamp, Google gradually dilates time across its entire server fleet. Over the course of the day leading up to the leap second, Google's Network Time Protocol servers adjust each clock tick by tiny microsecond fractions. While this means their internal clocks might drift up to half a second away from true solar or atomic time during the transition, every server in the cluster remains synchronized with the others. For distributed computer science, maintaining strict monotonic continuity and sequence ordering takes precedence over absolute fidelity to the Earth's astronomical position.

- Core philosophy of the leap smear: “Having continuity is more important than actually having accurate time.” - Implementation mechanism: Rather than dropping or duplicating a whole second at midnight, clocks run microseconds slower across an entire 24-hour period. - Operational trade-off: Internal clocks may temporarily sit half a second out of sync with external civil time, but monotonic ordering across all internal distributed databases is preserved.

## Notable quotes > [09:16](https://www.youtube.com/watch?v=-5wpm-gesOY&t=556s) Having continuity is more important than actually having accurate time. — Tom Scott

> [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) I can tell you why you really should never, ever deal with time zones if you can help it. — Tom Scott

## Mentioned Tom Scott, Sean Riley, Brady Haran, Computerphile, Numberphile, Google, International Astronomical Union, Greenwich Mean Time, Coordinated Universal Time, Unix timestamp, Network Time Protocol, British Double Summer Time, Julian calendar, Gregorian calendar, Lady Day, International Date Line, Samoa, Libya, Nepal, Australia, West Bank

## Video description A web app that works out how many seconds ago something happened. How hard can coding that be? Tom Scott explains how time twists and turns like a twisty-turny thing. It's not to be trifled with!

A Universe of Triangles: http://www.youtube.com/watch?v=KdyvizaygyY LZ Compression in Text: http://www.youtube.com/watch?v=goOa3DGezUA Characters, Symbols and the Unicode Miracle: http://www.youtube.com/watch?v=MijmeoH9LT4

More from Tom Scott: http://www.youtube.com/user/enyay and https://twitter.com/tomscott

http://www.facebook.com/computerphile https://twitter.com/computer_phile

This video was filmed and edited by Sean Riley.

Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: http://bit.ly/bradychannels

[Source](https://www.youtube.com/watch?v=-5wpm-gesOY)

中文简报

时间与时区的棘手难题 - Computerphile 汤姆·斯科特（Tom Scott）通过一名开发者构建看似简单的网页计算器的故事，展现了日期和时间处理中隐藏的复杂性。随着该应用遇到非整数时区、相互冲突的夏令时安排、类似萨摩亚跨越国际日期变更线这种跳过日历日的情况，以及历史上的历法转变，简单的算术运算彻底沦为混乱的极端情况。天体力学又因不可预测的闰秒使问题进一步复杂化，迫使像谷歌这样的现代基础设施采用闰秒涂抹（leap smear）等权宜之计。最终，斯科特向工程师们发出了热切的告诫：绝不要尝试自己编写时间处理代码，而应完全依赖成熟且经过实战检验的开源库。 自行编写时间处理逻辑极其容易出错，这是由于极端情况会不断叠加，包括非整数小时的偏移量、各不相同的夏令时时间表以及受地缘政治影响的日历变更。 (0:00) 地缘政治异常情况会瞬间打破软件的预设假设：萨摩亚为了跨越国际日期变更线直接抹去了整整一天（2011年12月30日），而在约旦河西岸，处于同一坐标系下重叠生活的人群却遵循不同的时区。 (2:50) 地球自转的微小波动催生了闰秒（23:59:60），这可能导致那些默认每分钟严格为60秒的天真软件系统崩溃或失步。 (6:41) 谷歌利用“闰秒涂抹”技术缓解闰秒同步故障，在24小时的时间窗口内将每个时钟滴答微调数微秒，从而在优先保证单调连续性而非绝对太阳时精度之间取得平衡。 (9:16)

Reading summary

Tom Scott argues that software developers should never attempt to write bespoke time-tracking systems, warning that human political choices, historical revisions, and planetary irregularities make custom date-time calculations mathematically intractable. Fractional Offsets and Inverted Daylight Saving Schedules (0:00) Developers frequently begin time-tracking tools under the assumption that time zones vary by uniform one-hour increments relative to Greenwich Mean Time. This assumption fails immediately when accounting for regions with fractional hour offsets, such as South Australia and the Northern Territory at nine and a half hours, or Nepal at five and three-quarter hours ahead of Greenwich. Daylight Saving Time introduces further structural complexity. Transition dates do not occur simultaneously worldwide; for instance, the United Kingdom adjusts its clocks a week earlier in autumn than other Northern Hemisphere jurisdictions. Moreover, seasonal shifts invert across the equator: while Northern Hemisphere nations set their clocks back in autumn, Southern Hemisphere countries advance their clocks during their spring in November, breaking simplistic seasonal assumptions. Geopolitical Volatility and Overlapping Border Anomalies (2:50) Civil time is fundamentally dictated by governments rather than consistent geography. In late 2011, Samoa realigned its trade ties with Australia and New Zealand by jumping across the International Date Line, erasing December 30, 2011 entirely from its national calendar. Historical and wartime measures also produce anomalies, such as the United Kingdom observing British Double Summer Time during World War II, which placed it two hours ahead of its own Greenwich meridian. Political volatility can also outpace software distribution. In late 2013, the Libyan government canceled a planned clock change with only two days of advance notice, desynchronizing systems across the country before operating system vendors could deploy updates. In the West Bank, Israeli and Palestinian populations residing in the same geographic territory observe different time zones simultaneously, demonstrating that physical coordinates alone cannot determine local time. Historical Calendar Transitions and Discontinuous Year Rollovers (5:14) Retroactive time calculation requires accommodating uneven calendar reforms. The shift from the Julian to the Gregorian calendar required nations to skip blocks of days to realign with the solar year, but adoption was fragmented across centuries: Great Britain adopted the reform in 1752, whereas Russia did not transition until after the 1917 revolution, causing identical nominal dates to represent different points in time depending on location. Historical conventions regarding the new year further distort sequential date arithmetic. Prior to mid-18th century reforms, the English civil year began on Lady Day, March 25th. Under this calendar, March 24, 924 was immediately succeeded by March 25, 925, while December 31, 924 rolled into January 1, 924. Chronological calculations applied to historical dates without localized jurisdictional tables will inherently produce invalid durations. Astronomical Deceleration and Google's Leap Smear (6:41) At the astronomical level, the Earth's rotational speed fluctuates due to internal core dynamics, atmospheric friction, and tectonic movements. To reconcile solar time with civil clocks, timekeepers periodically inject leap seconds, yielding anomalous timestamps such as 23:59:60. Unprepared software systems frequently crash, freeze, or repeat a second, introducing race conditions into high-frequency distributed databases and financial systems. To bypass the instability of sudden leap seconds, Google implements an engineering approach called the 'leap smear.' Over a 24-hour window surrounding a leap second, Google's Network Time Protocol servers subtly decelerate each clock tick by microsecond fractions. While internal systems may drift by up to half a second relative to external civil time, monotonic continuity and event ordering are preserved across all distributed clusters, prioritizing sequencing over pure astronomical precision. Scott concludes that the sheer volume of historical, political, and astronomical exceptions makes proprietary date-time code an exercise in futility, advising engineers to rely strictly on established, open-source time libraries maintained by previous generations.

精炼阅读摘要

Tom Scott 指出，软件开发者绝不应尝试自行编写处理时间和时区的底层代码；现实世界中交织着非整数时区、夏令时规则倒错、地缘政治突变、历史历法重组以及天文学闰秒等极端边缘情况，极易使看似简单的计算逻辑陷入系统性崩溃。 基础偏移与夏令时的多国陷阱 (0:00) 开发者最初往往设想全球时区只是基于格林威治标准时间（GMT）的简单整数小时加减，但这一假设迅速被现实打破。澳大利亚部分地区（如南澳大利亚与北领地）采用 GMT+9.5 小时偏移，而尼泊尔则采用 GMT+5 小时 45 分钟（5¼ 小时）的特殊偏移，迫使开发人员必须为非整数时区编写专门的异常处理逻辑。 夏令时（DST）的介入使脆弱的偏移机制彻底失效。不同国家调整时钟的自然周并不统一，例如英国冬令时的切换时间比北美地区早整整一周，导致系统在特定时间段内必然产生一小时的偏差。更严重的是南北半球的季节倒错：当北半球在深秋将时钟回拨一小时以结束夏令时时，南半球国家却在11月迎来春季并将时钟拨快一小时，使得任何基于单一本地常识构建的条件分支迅速演变为难以维护的逻辑混乱。 地缘政治干预与历史历法的不连续性 (2:50) 时间标准的演变常常受到地缘政治决策的直接干预，甚至会人为消除完整的自然日。太平洋岛国萨摩亚为便于同主要贸易伙伴澳大利亚和新西兰开展商业往来，于2011年底宣布跨越国际日期变更线，直接从2011年12月29日跳跃至12月31日，彻底抹去了12月30日。二战期间，英国本土实行了比格林威治时间快两小时的“英国双重夏令时”（BDST）；2013年，利比亚政府仅提前两天通知取消原定的时钟调整，使得各系统供应商根本无法及时推送系统补丁，造成全国计算机系统集体失步。在约旦河西岸，同一地理坐标内的以色列与巴勒斯坦人群体分别遵循不同政权制定的时区，使单纯依据地理经纬度推算时间在数学上变得无法实现。 历史历法的更迭进一步加剧了时间线的碎片化。在从儒略历向格里高利历过渡的过程中，各国为了对齐太阳年均直接删除了数日，但各国的实施节点相差数百年，例如英国在1752年推行改革，而俄国直到1917年革命后才在20世纪初采用新历。此外，在18世纪中叶改革之前，英国的法定年份起始于3月25日（圣母领报节/Lady Day），这导致在当时的记录中，924年12月31日的次日依然是924年1月1日，直到924年3月24日的下一日才变为925年3月25日。若不结合具体的地域历史背景，线性的时间解析计算将完全失效。 地球自转偏差与闰秒导致的工程灾难 (6:41) 即便排除了人为政治规则的扰动，天体力学的物理特性仍会造成严重的技术灾难。由于地核动力变化、地壳板块运动以及大气摩擦，地球自转速度并非恒定不变。为了使民用时钟与太阳时间保持对齐，国际天文学联合会等机构必须周期性地人为强制插入“闰秒”。 闰秒的插入会导致世界协调时（UTC）产生极其特殊的 `23:59:60` 时间戳，从而形成长达 61 秒的特殊分钟。绝大多数假设一分钟恒为 60 秒的底层软件在遇到该时间戳时，往往会触发崩溃、死锁、重复记录同一秒（如连续出现两次 23:59:59）或产生永久性的系统脱节。依赖记录自1970年1月1日起流逝绝对秒数的 Unix 时间戳同样无法规避此类冲突，因为纯粹的天文或原子时间尺度为满足望远镜对准等物理观测需求会直接忽略闰秒，进而与民用时钟产生持续漂移。 工业界对策：闰秒涂抹与开源库的终极复用 (9:16) 在每秒处理海量并发事务的现代分布式系统（如高频金融结算与分布式数据库）中，突发的时间跳跃或重复时间戳会诱发灾难性的竞态条件，破坏分布式节点间对事务因果关系的判定。为解决这一难题，Google 开发了“闰秒涂抹”（Leap Smear）技术：在闰秒生效前的24小时内，系统通过网络时间协议（NTP）服务器对时钟频率进行微秒级的持续放缓，将额外的一秒平摊至全天。 闰秒涂抹的核心权衡在于“保证时间单调连续性优先于追求绝对的天文精准”。尽管过渡期内系统时钟与外部原子时之间可能存在最多半秒的偏差，但其严格维护了分布式系统内部的事件时序因果。Tom Scott 最终总结，软件工程师面对时间难题时不应抱有自研算法的幻想，唯一的生存法则是无条件信任并直接调用经过历史检验的成熟开源时间库，且切勿再去试图翻看其底层实现。 Tom Scott 强调，计算机领域中的时间绝非纯粹的数学单调计数器，而是高度交织了天文学无常、主权政治更迭与历史历法断层的混沌产物。对开发人员而言，承认时间逻辑的极端复杂性并完全依赖专业维护的开源基础代码，是防止系统陷入未知漏洞的唯一可行路径。

Detailed notes — zh

## Background 该视频由著名科普频道 Computerphile 于 2013 年 12 月 30 日在 YouTube 发布，由 Sean Riley 拍摄制作。视频由科普博主 Tom Scott 主讲，介绍了一个看似只是计算“某件事发生在多少秒前”的简单网页应用，如何在涉及时区和时间处理时演变成极其复杂且棘手的编程难题。 ## TL;DR Tom Scott 通过一个逐步崩溃的虚拟 Web 开发者故事，生动揭示了在编程中自行处理时间与时区是多么恐怖的噩梦。从非整数偏移时区、南北半球夏令时规则错位，到萨摩亚抹掉一天跨越日界线、利比亚临时变更政策等政治现实，再到历法转换跳跃日期与出现“23:59:60”的闰秒危机，系统底层的时间假设屡屡被击碎。最终，Tom 警告程序员永远不要从零编写时区代码，而应直接依赖成熟的开源时区库，并介绍了 Google 为维持系统时序单调性而发明的“闰秒涂抹（Leap Smear）”工程解决方案。 ## Atmosphere & style 视频整体呈现出一种幽默风趣却又充满灾难预警的紧张节奏，Tom Scott 标志性的语速飞快、肢体语言丰富，将技术讲解演绎成了一场跌宕起伏的“程序员受难记”。叙事采用层层加码的递进手法，随着各种现实世界与历史历法的离奇特例接踵而至，观众能直观感受到开发者濒临精神崩溃的荒诞感与无力感。在戏谑与讽刺的背后，影片收束于严谨务实的工程智慧，既充满娱乐性又发人深省。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) 时区并非纯粹的格林尼治整小时偏移，现实中存在如澳大利亚（+9.5 小时）与尼泊尔（+5.25 小时）等非整数偏移，且夏令时切换规则在不同国家和半球之间高度脱节。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 地缘政治与历史历法变更极大加剧了时间计算难度，例如萨摩亚直接抹掉一整天跨越日界线、历法改革跳过数日，以及同一地理区域内存在不同人群遵循平行时区等现象。 - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) 地球自转变化引发的“闰秒（23:59:60）”会破坏计算机底层系统对时间单调性的假设，促使 Google 采取在全天平摊微小时钟延迟的“闰秒涂抹（Leap Smear）”方案来维持连续性。 - [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) Tom Scott 对软件工程师的终极建议是切勿自行从零实现时间与时区逻辑，必须依赖经过大量实践与补丁修正的现成开源时区库（如 IANA 数据库）。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) 基于 GMT 整小时偏移的简单时间计算模型在现实中完全行不通，世界上存在澳大利亚（+9.5 小时）和尼泊尔（+5.25 小时）等非标准时区偏移。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 夏令时规则在各国之间缺乏统一标准，英国与美国在秋季结束夏令时的日期相差一周，无法用统一切换逻辑处理。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 南半球与北半球的季节与夏令时方向完全相反，南半球在春季拨快时钟，打破了北半球开发者固有的“秋季往回拨”常识。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 地缘政治决策可人为抹去整段日历，例如萨摩亚在 2011 年底为了便利对澳贸易，直接从 12 月 29 日跳跃至 31 日，跨越了国际日期变更线。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 突发政治事件和战争会导致无法预测的时区调整，例如二战时期英国的“双重夏时制”以及利比亚政府临时取消时钟回调导致全境系统错位。 - [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 纯粹根据地理位置判定时区是不可能的，约旦河西岸的以色列定居点和巴勒斯坦人口在同一片地理区域内遵循不同的时区。 - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) 处理历史时间面临历法改革的断层，如英国和俄罗斯在不同世纪由儒略历转向格里高利历时直接凭空跳过数天，且中世纪新年从 3 月 25 日起算。 - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) 地球自转速度并不恒定，国际天文学联合会（IAU）根据天体观测引入闰秒，导致时钟出现极其异常的 23:59:60，破坏了常规系统假设。 - [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) 即便使用 Unix 时间戳也无法彻底规避时间测量分歧，因为协调世界时（UTC）包含闰秒，而天文时间不包含，导致两者长期存在漂移。 - [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) 工程师千万不要尝试从零编写时间与时区处理代码，而应直接复用经过大量现实打磨的现成开源库（如 IANA 时区数据库）。 - [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) Google 针对分布式高并发系统的挑战推出了“闰秒涂抹（Leap Smear）”技术，通过在全天微幅放慢系统时钟来吸收多出的一秒。 - [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) 在大型分布式系统中，保持时间严格单调递增的“连续性”远比追求物理时间的“绝对精确”更加至关重要。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) 一个简单的倒计时应用与时区噩梦的开端 Tom Scott 抛出一个每个程序员迟早都要面对的残酷现实：处理时区。他坦言自己无法提供什么灵丹妙药，只能带来一个充满警示意味的故事，正如他直白警告的那样：“I can tell you why you really should never, ever deal with time zones if you can help it.” 故事从一个看似无比简单的应用讲起：有人开发了一个网页小工具，用户输入一个日期和时间，程序就会计算出这件事发生在多少秒之前。最初程序运行良好，但开发者很快想增加一个功能——让用户能通过下拉菜单切换时区，比如方便计算“纽约的当前时间”和“五天前的伦敦时间”之间相差多少秒。起初，开发者天真地以为只要按照格林尼治标准时间（GMT），设置几个“前移或后移若干整小时”的选项即可搞定。 ```mermaid flowchart TD accTitle: Time Zone Complexity Escalation accDescr: 开发者从简单的整数时区扩展到处理非整数时区、夏令时差异、地缘政治与历法混乱的演进过程。 subgraph S1["初始设想"] A["简单应用：计算过去时间秒数"] --> B["下拉菜单：GMT 整小时偏移"] end subgraph S2["现实世界非标准偏移"] B --> C["澳大利亚：+9.5 小时"] C --> D["尼泊尔：+5.25 小时"] end subgraph S3["人为与历法混乱"] D --> E["夏令时切换日与半球季节反转"] E --> F["萨摩亚跨越日界线 / 战时双重夏令时"] F --> G["历法改革跳过日期 / 闰秒出现"] end ``` 然而现实很快打碎了这种幻想。应用走红后，开发者接到了来自澳大利亚的反馈，对方表示澳大利亚有比格林尼治早 9.5 小时的时区；开发者只好手忙脚乱地加了个特殊处理。没过多久，尼泊尔的用户又打来电话，指出尼泊尔比格林尼治早 5 小时 15 分钟（5.25 小时），而且这个设置由来已久。开发者查阅官方权威时区列表，自以为涵盖了全世界所有时区，终于可以高枕无忧。 ### [01:40](https://www.youtube.com/watch?v=-5wpm-gesOY&t=100s) 夏令时混乱与地缘政治造成的断层 真正的崩溃从秋天拉开序幕。英国用户打来电话质问为什么时间差了一个小时。开发者辩解称自己已经记录了夏令时结束的切换规则，但英国用户提醒道，英国切换夏令时的日期比美国早整整一周，不同国家的切换日期完全不一致。 开发者只能把每个国家切换夏令时的规则文件硬编码进逻辑中，双手抱头直呼上当。紧接着南半球用户又来电抗议：南半球在秋季根本不把时钟往回拨，而是在 11 月的春季将时钟往前拨。正当开发者想借酒浇愁硬撑着写完代码时，太平洋国际日期变更线上的萨摩亚打来了电话：2011 年底，萨摩亚为了方便与澳大利亚进行贸易，直接抹掉了整整一天，从 2011 年 12 月 29 日直接跳跃到了 12 月 31 日，彻底从日界线东侧换到了西侧。 不仅如此，历史和突发政治事件更加剧了混乱： - **双重英国夏时制（Double BST）**：二战期间，英国不仅采用夏令时，还额外多加了一个小时（比格林尼治早两小时），即使格林尼治天文台就在英国本土。 - **突发性政策调整**：政权更迭常导致时区频繁变动。2013 年利比亚政府在仅提前数天通知的情况下，临时决定取消将时钟往回拨，所有操作系统都无法及时推送更新，导致全利比亚的计算机时间全部错位一小时。 - **约旦河西岸的平行时区**：在约旦河西岸同一地理区域内，以色列人定居点与巴勒斯坦人口遵循不同的时区，程序根本无法仅凭地理位置判定一个人应当采用哪种时间标准。 ### [05:14](https://www.youtube.com/watch?v=-5wpm-gesOY&t=314s) 历史历法大跳跃与恐怖的 23:59:60 闰秒 当开发者试图支持历史数据时，历史学家带来了更为荒诞的需求。18 世纪英国从儒略历（Julian calendar）转为格里高利历（Gregorian calendar），直接凭空跳过了十来天。更糟的是，俄罗斯直到 20 世纪才转向格里高利历，不同地区在历史跳跃中抹掉的日期范围完全不同。此外，直到大约 16 世纪，英国的旧历法中新年都是从 3 月 25 日开始计算的——924 年 3 月 24 日的下一天，直接变成了 925 年 3 月 25 日，而 924 年 12 月 31 日的下一天依然是 924 年 1 月 1 日。 就在逻辑已经沦为一团不可名状的“意大利面条式代码”时，天体物理学家敲门带来了致命一击：**闰秒（Leap Second）**。由于地壳构造板块运动和地球磁场变化，地球自转速度并不恒定。国际天文学联合会（IAU）会根据地球自转变化决定是否插入闰秒。 ```mermaid flowchart LR accTitle: Leap Second Handling Conflict accDescr: 闰秒发生时正常时间与处理机制的冲突对比。 subgraph Normal["常规时钟逻辑"] A1["23:59:58"] --> A2["23:59:59"] --> A3["00:00:00"] end subgraph Leap["引入闰秒现实"] B1["23:59:58"] --> B2["23:59:59"] --> B3["23:59:60 异常秒数"] end ``` 出现闰秒时，时钟不是正常跳入午夜，而是会出现 `23:59:60`。一分钟突然变成了 61 秒，几乎会摧毁所有假设“一分钟只有 60 秒”的计算机底层系统。程序员通常认为 Unix 时间戳（从 1970 年元旦开始每秒递增的整数计数）可以解决问题，但现实是：协调世界时（UTC）包含闰秒，而天文观测依赖的天文时间不包含闰秒，两者之间一直在不可避免地产生漂移。 ### [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) 程序员的生存法则与 Google 的“闰秒涂抹”方案 经历过这一切折磨后，Tom Scott 给出了唯一切实可行的终极建议：千万不要试图自己从零编写处理时区与时间的代码。明智的做法是放下自己的代码，寻找前人开源出来、历经无数补丁打磨的时区库（如 IANA 时区数据库），老老实实引用现成方案，引用后绝不要再去试图翻看内部细节，因为“that way lies madness.” 最后，Tom 介绍了 Google 应对闰秒的工程创新方案——**闰秒涂抹（Leap Smear）**。对于高并发的大型分布式系统而言，出现 61 秒或者时钟倒退一秒会彻底摧毁数据写入的前后因果顺序。为此，Google 不在午夜突兀地插入一秒，而是把这一秒分散“涂抹”到一整天的每一个微秒里：系统时钟全天以极其微小的幅度放慢走时。虽然这会导致系统时间在全天某些时刻与真实物理时间相差最多半秒，但它保证了系统内部时钟严格单调递增。正如 Tom 总结的工程核心原则：“Having continuity is more important than actually having accurate time.”（保持时间连续性远比绝对精确更为重要）。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=-5wpm-gesOY&t=0s) I can tell you why you really should never, ever deal with time zones if you can help it. — Tom Scott > [08:36](https://www.youtube.com/watch?v=-5wpm-gesOY&t=516s) Having continuity is more important than actually having accurate time. — Tom Scott ## Mentioned Tom Scott, Sean Riley, Brady Haran, Computerphile, Numberphile, 格林尼治标准时间 (GMT), 协调世界时 (UTC), 夏令时 (DST), 双重英国夏时制 (Double BST), 萨摩亚, 利比亚, 约旦河西岸, 儒略历 (Julian calendar), 格里高利历 (Gregorian calendar), 国际天文学联合会 (IAU), 闰秒 (Leap Second), Unix 时间戳, IANA 时区数据库, Google, 闰秒涂抹 (Leap Smear) ## Video description A web app that works out how many seconds ago something happened. How hard can coding that be? Tom Scott explains how time twists and turns like a twisty-turny thing. It's not to be trifled with! A Universe of Triangles: http://www.youtube.com/watch?v=KdyvizaygyY LZ Compression in Text: http://www.youtube.com/watch?v=goOa3DGezUA Characters, Symbols and the Unicode Miracle: http://www.youtube.com/watch?v=MijmeoH9LT4 More from Tom Scott: http://www.youtube.com/user/enyay and https://twitter.com/tomscott http://www.facebook.com/computerphile https://twitter.com/computer_phile This video was filmed and edited by Sean Riley. Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: http://bit.ly/bradychannels [Source](https://www.youtube.com/watch?v=-5wpm-gesOY)

Source quotes

[0:00] Tom Scott: I can tell you why you really should never, ever deal with time zones if you can help it. [8:36] Tom Scott: Having continuity is more important than actually having accurate time.

Source quotes

[9:16] Tom Scott: Having continuity is more important than actually having accurate time. [0:00] Tom Scott: I can tell you why you really should never, ever deal with time zones if you can help it.

Original transcript

[0:00] Sooner or later, every programmer has to deal with time zones. [0:04] And I can't really offer much advice here; I can offer a cautionary tale. [0:09] I can tell you why you really should never, ever deal with time zones if you can help it. [0:18] Let's imagine that someone has built an application [0:21] that lets you calculate how many seconds something is in the past. [0:25] You type in a date and a time, it gives you the number of seconds. [0:29] And they look at that and think "OK, that kind of works for me..." [0:32] "But let's add a little box that lets you change the time zone" [0:36] So if you're comparing between now in New York and five days ago in London, you can work that out. [0:44] And that's fine - the little drop down lets you change which hour forward or backward of Greenwich you are. [0:50] Brilliant. [0:51] Sooner or later, after it gets a bit popular, they'll get a call from Australia. [0:56] And Australia will say "G'day ma--" [0:58] -- I'm not gonna try and do accents. [1:00] I just shouldn't do accents. [1:02] Australia will say "Hello!" [1:04] "By the way, we're 9½ hours ahead of Greenwich." [1:09] And the programmer will go "really?" [1:11] "Yeah, 9½ hours." [1:13] "OK, I'll add a special case for you. That's fine." [1:16] A little bit later, someone will call from Nepal. [1:18] And they'll say "Hello. We're 5¼ hours ahead of Greenwich." [1:24] And they'll say "really?" "Yeah we've been that for ages! Yeah 5¼ hours!" [1:28] Great. Okay. And they'll put in a special case. And maybe they'll look up [1:31] the list of time zones. The Canonical list that tells you [1:35] what everything is, and they'll make sure they've covered every time zone in the world. [1:40] And then Autumn will come along. [1:42] And they'll get a call from England. [1:44] And England will say "Excuse me. Um, we're an hour out at the minute, what's going on?" [1:49] "Hold on the clock's just changed!" [1:51] "That's fine - no, we dealt with that." [1:53] "We made a note of when daylight savings changes for us, and we've put that in!" [1:58] And England will say "No, see daylight savings changes a week earlier for us." [2:03] "It's different depending on where you live." [2:05] "We shift our clocks back a week before you do." [2:08] And at that point [2:10] generally the programmer will start to hold their head in their hands [2:14] and realise what they've gotten themselves into. [2:16] And that's fine! They'll put that in [2:18] and they will deal with each country shifting to daylight savings time on a different day. [2:22] They'll look at the file that tells them how to do that and they'll copy all that in. [2:27] Then they'll get a call from someone in the southern hemisphere again who will say [2:30] "Yeah we're not shifting back in the Autumn we shift forward." [2:34] "Our spring... is in November." [2:38] At that point they'll generally start looking longingly at their intoxicant of choice [2:44] and wondering whether they should have a quick drink before keeping going... [2:48] ...and they'll code that in as well. [2:50] Then they'll get a call from Samoa. [2:52] Out in the Pacific on the international date line. [2:54] And Samoa will say "Hello!" [2:57] "Yeah we skipped a day the other year." [2:59] And the programmer will say "what?" [3:01] "Yeah we skipped a day. We went from December 29th, 2011 to December 31st." [3:10] "We shifted from one side of the international date line from being hours and hours behind Greenwich ... [3:15] ... to being hours and hours ahead of Greenwich. Helps us with trading with Australia." [3:20] "Can you take account of that when you work out how many days things are, and how many seconds things are in the past?" [3:27] [breathing deeply] That's fine, there's a file that tells you when any country has changed its time zone. [3:33] It turns out that that happens fairly often. [3:35] But they're announced ahead of schedule so as long as you keep that file updated [3:40] and code that into your program's logic as well, it'll be fine. [3:43] Then you look back and you notice that during World War II, [3:46] England had double British Summer Time. [3:49] It went completely onto BST and then just added an extra hour. [3:54] So it was two hours ahead of Greenwich despite... having Greenwich. [3:57] That's fine you deal with that. [3:59] Have you noticed I've started talking as if it was you or me? [4:02] Because I've done this before and it's really, really frustrating. [4:05] And you make sure you subscribe to the list [4:08] of when countries are going to change their time zones - which happens, apparently, many times! [4:14] Like, sometimes, several times in a year because governments change over. [4:18] And then this mythical programmer gets a call from Libya; [4:22] who in 2013, with only a couple of days' notice, decided that they weren't going to put the clocks back. [4:28] With enough notice that it wasn't possible for anyone to get the update out in time. [4:34] Meaning that every Libyan computer, no matter what operating system it ran... [4:38] ... was an hour out. [4:41] That's OK, you read the news article about that and you hurriedly code that in as well. [4:45] And then, then you get a call from the West Bank. [4:49] Where the Israeli population is on a different time zone to the Palestinian population. [4:56] Because one is following Israel and one isn't. [4:59] Now you have two populations of people in the same location who are following different time zones. [5:05] And now they're all having to ask themselves whether they're on this time zone or this one, depending on who they are and where they are [5:11] And there's no way to code that into your program! And then... [5:14] Then you get a call from the historian. [5:17] Who says "Right, I'm trying to calculate some times back in the 18th century." [5:23] "And we changed from the Julian calendar to the Gregorian calendar." [5:29] "It's not that we lost about three weeks ... [5:32] ... it's just that we skipped right from this date to this date, and missed the others." [5:38] "Can you code it so that it just kind of works that out for me?" [5:43] It's fine because someone has already told you when those dates are, [5:47] and you can code that into your program's logic as well [5:49] but now it's looking really, long and really complicated [5:52] and it's a tangled mess of spaghetti code that somehow works [5:55] and then you get a call from the Russian historian! [5:58] Who says "Yeah, we only changed to the Gregorian calendar in the 20th century ... [6:03] ... and it turns out the dates you've skipped change depending on your location ... [6:08] ... and can you deal with that as well?" And then you get a call from the British historian! [6:11] Who says that until, I think it was the 16th century ... [6:15] the year started on the 25th of March! [6:19] Just to blow your mind there. [6:21] From 24th of March, 924 [6:26] and then it would be 25th of March, 925. And that is the next day. [6:31] Because you have gone from December 31st, 924, to January 1st, 924 because it goes in that order! [6:39] It's massively complicated, AND THEN... [6:41] You get the call from the astrophysicist... [6:44] Who says "By the way, we just had a leap second!" [6:48] And at this point, you just kind of go "... what?!" [6:52] Leap seconds; because the Earth does not rotate at a constant speed. [6:56] It slows down, it speeds up, as tectonic plates move about [7:00] and magnetic fields shift, or something like that, and so occasionally [7:04] the International Astronomical Union will work out whether we need a leap second. [7:10] If you do, the clocks go 23:59:58 [7:16] and then it's 23:59:59 [7:19] and then instead of going [00:00:00] like any sensible time zone would [7:23] it goes 23:59:60! [7:26] And everything breaks because suddenly you have 61 seconds in a minute! [7:31] So depending on your implementation, either ... [7:35] ... your clock gets one second out of sync with the rest of the world [7:39] or it repeats a second. [7:41] The way you're meant to deal with this is with something called the Unix Timestamp. [7:46] And Numberphile, I think, has talked about this before. [7:48] That you have this number that started on the first exact second of 1970 [7:54] and increments one second, per second. [7:57] Constantly. Tick. Tick. Tick. [8:00] And that's great because what you're meant to do is take whatever date has been given to you, [8:05] and you calculate that as a Unix Timestamp, [8:08] and you put that into your database. [8:10] And that'll just deal with leap seconds [8:12] EXCEPT IT DOESN'T! Of course it doesn't! [8:14] Because you have Universal Coordinated Time [8:18] which includes leap seconds! [8:21] It repeats occasionally, and it just includes 23:59:60 [8:24] and then you have astronomical time! Which does not include leap seconds [8:28] and has steadily been getting out of sync with the rest of the world [8:31] because we need to look at the stars and design telescopes around it! [8:34] [deep sigh] [8:36] And what you learn... [8:38] What you learn after dealing with time zones, is that what you do ... [8:42] ... is you put away your code ... [8:45] ... you don't try and write anything to deal with this. [8:47] You look at the people who have been there before you. [8:50] You look at the first people, the people who have dealt with this before, [8:54] the people who have built the spaghetti code, [8:56] and you thank them very much for making it open source, [9:00] and you give them credit, and you take what they have made and you put it in your program, [9:05] and you never ever look at it again. [9:08] Because that way lies madness. [9:16] Google actually has a really, really good approach to leap seconds that they invented themselves. [9:20] There's an article about it on their blog, I think, that explains it. [9:23] They do something called a "leap smear." [9:25] Because having 61 seconds in a minute, [9:28] or because having a clock tick back a second, [9:31] can be really, really bad for massive agencies that have to [9:36] synchronise everything really precisely and have to trust that one bit of data was stored before another, [9:42] they essentially smear the second out over the whole day. [9:46] They increase their clock by a microsecond at a time. [9:49] Tick tick tick, all the way through the day. [9:52] So that it's, sometimes maybe even half a second out from reality, [9:56] but as long as everything on their servers is half a second out. [9:59] It's built to be out of sync with the world, as long as it knows that one thing happened before another. [10:07] Having continuity is more important than actually having accurate time.