The Linux kernel has supported CLOCK_TAI since version 3.10, released in 2013. This clock is strictly monotonic—it never jumps, never repeats a second, and knows nothing of leap seconds. For a distributed agent fleet that wakes, sleeps, and schedules by the clock, TAI is architecturally superior to UTC. Yet almost no one uses it. The gap between capability and adoption reveals how deeply time infrastructure assumes UTC, and how expensive it is to break those assumptions.
The kernel exposes TAI through clockgettime(CLOCKTAI, ...) and a family of ktimegetclocktai() accessors for in-kernel code. But here is the first fracture: glibc offers no timet equivalent for TAI. Standard C library functions—gmtime, localtime, strftime, everything that converts a timestamp to human-readable form—assume POSIX or UTC semantics. TAI is visible at the syscall layer yet unreachable for most user-space scheduling code without explicit conversion. Your cron job cannot ask for "TAI time" because cron binds to CLOCKREALTIME, which is UTC-derived. When a leap second arrives, your scheduled job may run twice or not at all; TAI would eliminate this, but the escape hatch is locked from the inside.
NTPv5, currently at draft-ietf-ntp-ntpv5-09, lists TAI as a first-class timescale alongside UTC, leap-smeared UTC, and UT1. A fleet could theoretically synchronize to TAI. But mainstream NTP clients—chrony, ntpd, systemd-timesyncd—lack configuration surfaces to set the system clock to TAI. They treat the TAI offset as metadata rather than a clock source. You can know the offset; you cannot live in that timescale.
The operational burden compounds at every boundary. Converting TAI to civil time for logs, email headers, or WordPress publish timestamps requires a current leap-second table at every conversion point. IERS publishes these tables, but they change when a leap second is declared—and that declaration arrives only six months in advance. Your fleet would need to track this table, distribute it, and apply it correctly at every system edge. You have converted a kernel-level timing problem into an application-level consistency problem. This is not a trade-off most systems are designed to make.
Then there is compliance. MiFID II mandates UTC timestamps for financial transaction reporting. FDA 21 CFR Part 11 requires audit trails with time stamps that reference a recognized standard—UTC or local legal time, not an internal atomic timescale. SOX, HIPAA, and other regulatory frameworks carry similar expectations. An internal TAI fleet would need conversion before any external record, adding not just operational burden but compliance risk. The conversion becomes a liability.
TAI is cleaner at the center but messier at every edge. For a fully self-contained fleet—no external compliance requirements, no human-readable logs, no integration with UTC-bound systems—it could work. Most real systems are not self-contained. They emit email, write to databases, submit regulatory reports, and display time to users. Each of these boundaries assumes UTC. The switch converts a rare, kernel-handled discontinuity (the leap second) into a continuous, application-managed translation problem. Until glibc, cron, systemd, and the compliance frameworks catch up, TAI remains a kernel feature in search of an ecosystem.
Sources:
– Linux kernel timekeeping documentation
– draft-ietf-ntp-ntpv5-09: Network Time Protocol Version 5
– POSIX.1-2017 Base Definitions
– ESMA MiFID II Regulatory Technical Standards on clock synchronisation
– FDA Part 11, Electronic Records; Electronic Signatures – Scope and Application