Seconds Since the Epoch

What POSIX / Unix Time Actually Represents

• Many assumed “Unix time = seconds since 1970-01-01 00:00:00 UTC.”
• Commenters clarify POSIX more precisely as:
  • 86400 * (number of UTC midnights since epoch) + (seconds since last UTC midnight),
  • which ignores leap seconds by treating every UTC day as 86400 seconds.
• Result: Unix time is effectively “seconds since epoch, minus leap seconds” and is off by ~27–29 seconds compared with true elapsed SI seconds, depending on how you count.

Leap Seconds: Behavior and Confusion

• On positive leap seconds, many systems repeat a timestamp: e.g. ...799 → 800 → 800 → 801.
• This means:
  • Some real instants have no POSIX timestamp (during smeared or skipped behavior).
  • Some timestamps correspond to two distinct real instants.
• There is confusion in the thread about whether leap seconds are “real seconds,” whether they’re inserted or smeared, and how many there have been since 1970.
• Negative leap seconds (removing a second) are theoretically possible and largely unhandled.

Monotonicity, Synchronization, and Precision

• Unix time is not strictly increasing in UTC terms (due to repeated seconds); some argue this breaks the idea of a monotonic counter.
• High-precision synchronization examples are discussed:
  • GNSS/GPS, GPSDOs, PTP, and WhiteRabbit (sub-nanosecond sync) vs. typical NTP (millisecond-level).
• Others note real-world constraints: clock drift, network latency, spoofing/jamming, and the difficulty of relying on wall-clock time for distributed ordering.

Storing and Representing Time

• Common practice: store timestamps as Unix epoch seconds (often UTC) and keep timezone separately.
• Some argue systems should instead store TAI-like monotonic time and convert to UTC/time zones only at the edges.
• Others warn that deviating from widely used Unix/UTC conventions is costly and most apps don’t care about ±1 second over decades.
• Databases differ: many “timestamp with time zone” types actually store instants in UTC and discard original zone; true zone round-tripping is rare and debated.

Human vs Machine Time & Future Changes

• Thread distinguishes:
  • Machine time: monotonic counters for intervals and ordering.
  • Human time: calendars, time zones, DST, solar alignment.
• Future calendar arithmetic is inherently uncertain (DST and legal changes). Storing user intent (local date+time+zone) is often recommended.
• There is an ongoing plan to abolish new leap seconds by ~2035; some see this as pragmatic, others dislike drifting away from mean solar time and argue we should then just adopt TAI explicitly.