Unix Time and the 2038 Problem: What a Timestamp Really Is

Epoch zero and the second counter

Timestamp 0 is the instant 1970-01-01 00:00:00 UTC; positive numbers count seconds forward and negative ones count back before it. A 2020s-era value sits around 1.7 billion - not a coincidence, just seconds since 1970. Because it is one monotonic integer, it is ideal for comparing and sorting instants, which is why systems store it instead of a formatted string.

The catch is human reading: 1700000000 tells a person nothing, so you always format it with a zone - and formatting in local time is where two people can disagree about the same instant.

Seconds versus milliseconds: the digit-count bug

Systems disagree on the unit. JavaScript's Date.now() and many APIs return milliseconds (13 digits), while classic Unix time is seconds (10 digits). Feed a 13-digit millisecond value into something expecting seconds and you get a date in the far future; feed seconds into a milliseconds parser and you get a date near 1970. This single mismatch causes an outsized share of timestamp bugs.

The converter exposes a seconds / milliseconds choice so you decode the right unit explicitly instead of guessing from the digit count. When storing, be consistent about which one you keep, and label it.

UTC versus local time

A timestamp is an instant, but a formatted date is a view of that instant from some zone. The robust habit is to store and compute in UTC and only convert to a local zone at display time, because storing local times loses information (and is ambiguous across daylight-saving changes). The converter's multiple-timezone output exists precisely so you can see the same instant rendered correctly wherever the user is.

The two landmark bounds bracket the 2038 problem: a signed 32-bit seconds counter simply cannot name a moment past 2038-01-19 03:14:07 UTC, and on the next second it rolls backwards.

Why 2038, and where it still bites

The 2038 problem is a fixed-width integer overflow: time stored as a signed 32-bit number of seconds tops out at 2147483647 (2038-01-19 03:14:07 UTC), after which it wraps to a negative value and the date jumps to 1901. It is not a distant theoretical worry for modern 64-bit systems, but it is real for legacy 32-bit hardware and firmware, old file formats, embedded devices, some databases that store time in a 32-bit INT column, and any code compiled on a 32-bit platform.

The fix is boringly good practice: store time in a 64-bit field (which reaches roughly 292 billion years - effectively never) or in a fixed string/UTC format, and audit old systems and schemas for 32-bit time columns before they meet 2038 data.

Leap seconds and the honest caveat

Unix time pretends every day is exactly 86,400 seconds and ignores leap seconds, so a UTC minute that really contained 61 seconds is represented as if it had 60 (the extra second is handled by smearing or repeating a value). For almost every application this is invisible and harmless. Only precision timekeeping, trading or telecom systems need to care, and they use TAI or explicit leap-second tables rather than raw epoch seconds.

For everyday work, use the converter to translate an epoch value into UTC and your local zone, and the date calculator when you need to add or subtract calendar days rather than raw seconds.