Time in Computing
Clocks, Timestamps, and Synchronization
Learn Computer TimeComputers need accurate time for logging, scheduling, security certificates, database transactions, and countless other operations. Understanding how systems measure, store, and synchronize time is essential for developers, administrators, and anyone troubleshooting time-related issues.
How Computers Keep Time
Hardware Clocks
- RTC (Real-Time Clock): Battery-backed chip that keeps time when power is off
- Crystal oscillator: Quartz crystal providing stable frequency (typically 32.768 kHz)
- Drift: Hardware clocks drift seconds to minutes per month
System Clock
- Software clock maintained by the operating system
- Initialized from RTC at boot
- Synchronized via network protocols (NTP)
- Can be adjusted more frequently than RTC
Network Time Protocol (NTP)
NTP synchronizes computer clocks over a network, achieving millisecond accuracy over the internet and sub-millisecond on LANs.
Stratum Levels
| Stratum | Source | Accuracy |
|---|---|---|
| 0 | Atomic clock, GPS receiver | Nanoseconds |
| 1 | Directly connected to stratum 0 | Microseconds |
| 2 | Synced to stratum 1 | Milliseconds |
| 3-15 | Each level syncs to one above | Degrades slightly |
How NTP Works
- Client sends request with timestamp
- Server responds with its timestamps
- Client calculates network delay and offset
- Clock is gradually adjusted (slewed) to avoid jumps
Time Storage Formats
| Format | Example | Use Case |
|---|---|---|
| Unix timestamp (s) | 1705329000 | Databases, APIs |
| Unix timestamp (ms) | 1705329000000 | JavaScript, Java |
| ISO 8601 | 2024-01-15T14:30:00Z | JSON, APIs, logs |
| RFC 2822 | Mon, 15 Jan 2024 14:30:00 +0000 | Email headers |
| SQL DATETIME | 2024-01-15 14:30:00 | Databases |
| SQL TIMESTAMP | 2024-01-15 14:30:00 | Auto-updating fields |
Distributed Systems Challenges
Clock Skew
Different machines have slightly different times, causing:
- Out-of-order events in logs
- Race conditions in distributed transactions
- Certificate validation failures
Solutions
- NTP/PTP: Keep clocks synchronized
- Logical clocks: Vector clocks, Lamport timestamps
- Consensus protocols: Raft, Paxos for ordering events
- TrueTime (Google): GPS-synchronized with bounded uncertainty
Common Time Issues
Y2K Problem (1999-2000)
Two-digit years couldn't represent 2000. Cost billions to fix worldwide.
Year 2038 Problem
32-bit Unix timestamps overflow on January 19, 2038. Migration to 64-bit ongoing.
Leap Second Bugs
Some systems crash when clocks show 23:59:60. Leap seconds being phased out by 2035.
DST Transition Bugs
Scheduled tasks may run twice or skip during DST changes.
Best Practices
- Use UTC internally: Store and process in UTC; convert for display
- Use ISO 8601: Unambiguous, sortable format
- Include timezone info: 2024-01-15T14:30:00+05:30, not just "14:30"
- Synchronize via NTP: Keep all servers within milliseconds
- Test edge cases: DST transitions, leap years, year boundaries
- Use 64-bit timestamps: Avoid 2038 problem
Conclusion
Computer time involves hardware clocks, operating system synchronization, and network protocols working together. NTP keeps clocks accurate across networks. Store times in UTC with timezone information; use ISO 8601 format for interchange. Be aware of edge cases like DST transitions, leap seconds, and the 2038 problem. In distributed systems, clock synchronization is fundamental to correctness.