10 years ago, someone wrote a test for Servo that included an expiry in 2026
A decade-old automated test in Mozilla’s experimental Servo browser engine recently started failing because it used a hardcoded expiration date of 2026, prompting broader reflection on how engineers handle time in software. Commenters weigh the trade-offs between simple fixed dates, dynamic date calculations, and dedicated “fake time” frameworks, and connect this to historical issues like Y2K, the 2038 problem, and long-lived feature flags or certificates. Many argue that while quick fixes are tempting, systems should be designed to make time dependencies explicit and testable to avoid hidden failures decades later.
Hardcoded Test Dates and “Temporary” Fixes
- Many see the original hardcoded expiry in the Servo test as a classic “temporary fix” that became de facto permanent.
- Some argue extending the date is low-risk and simple; others say it just hides the real problem and should have been “now + delta” instead.
- A few suggest deliberately choosing a near-future expiry to force a proper fix instead of quiet deferral.
Time Constants and Long-Term Bugs
- General sentiment: any time constant will eventually be exceeded; “end of time” values inevitably become real dates.
- Examples: using “now + 100 years” for “forever,” end of 32-bit Unix time as a “never” sentinel, and far-future limits after 2038 that only push problems to later centuries.
- Jokes about bugs surfacing millions of years out underscore the known practice of kicking the can beyond one’s career or lifetime.
Randomness, Flaky Tests, and Property-Based Ideas
- One camp advocates adding limited randomness (e.g., offset days) to catch overlooked edge cases and avoid test coupling.
- Another warns that non-determinism in CI creates flaky tests that people ignore; recommends confinement to fuzz/property tests with fixed seeds and strong logging.
- Discussion notes that flaky tests often expose real bugs, but only if developers actually investigate them.
Handling Time in Tests (Clocks, Timezones, Fake Time)
- Several commenters argue tests should control time explicitly: pass “now” as a parameter or use fake-time frameworks / clock abstractions to make behavior deterministic.
- Others point out hazards: timezones, DST, month-length differences, and “frozen time” libraries causing subtle cache, serialization, and timeout issues.
- There’s debate whether fake-time strategies simply defer future date bugs to production unless a wide range of dates is explicitly tested.
Y2K, Preparedness, and Climate Analogy
- Multiple comments frame Y2K as a success of early warning and massive remediation, not a hoax.
- The “preparedness paradox” is cited: when preventive work succeeds, people think the original risk was exaggerated.
- Some draw a contrast with climate change, arguing that despite heavy scientific warning, comparable coordinated action and success have not occurred.
Intentional Expiries: Feature Flags and Certificates
- Some teams intentionally use expiry dates as “forced code review” mechanisms, e.g., feature flags that must expire within a year to avoid permanent cruft.
- Others describe long-lived SAML or SSL certs as unavoidable “time bombs” that create painful coordination events years later.