Unix Timestamp Converter

Unix Timestamps: Seconds vs Milliseconds, the 2038 Problem, and Eight Common Bugs

What a Unix timestamp actually is

A Unix timestamp is the number of seconds elapsed since 1970-01-01 00:00:00 UTC. It is an absolute instant and has no time zone attached to it. That starting point, called the Unix epoch, was chosen without deep meaning — it was simply a convenient integer to compute from when Unix was designed.

A current second-level timestamp is roughly 1.7 × 109 (10 digits), while a millisecond-level one is about 1.7 × 1012 (13 digits). Counting the digits is the fastest way to tell them apart.

It does not count leap seconds

A detail many developers miss: Unix time ignores leap seconds. It is not the literal count of physical seconds since 1970. Instead it is a counter aligned roughly to UTC but advanced by a fixed 86,400 seconds per day, exactly as the POSIX standard defines it. The benefit is that inserting a leap second never makes time appear to jump backward or forces special handling.

The consequence: Unix time and true physical elapsed time now differ by roughly 27 seconds (the accumulated leap seconds to date). This is irrelevant for almost all applications, but astronomy, finance with strict physical interval requirements, and any system doing precise interval math must account for the gap.

The 2038 problem

The largest signed 32-bit integer is 2³¹ − 1 = 2147483647, which maps to 2038-01-19 03:14:07 UTC. Past that value, any system storing the timestamp in a 32-bit integer overflows and wraps around to 1901-12-13.

Typical places this bites:

• An INT column in a database holding a timestamp. MySQL's INT is a signed 32-bit type; switch to BIGINT, DATETIME, or TIMESTAMP.
• C's time_t is still 32-bit on 32-bit platforms. 64-bit platforms are unaffected.
• Embedded devices, legacy systems, and file formats with fixed-width time fields.
• Protocol fields that legally mandate a 32-bit seconds representation need a new version to survive past 2038.

The good news: all mainstream 64-bit systems are free of this limit. A signed 64-bit integer tops out around 292 billion years from now, far beyond any realistic need. So your audit should focus on column types in storage and old hardware, not on modern application code.

Seconds versus milliseconds confusion

This is the single most common timestamp mistake. The same instant written in two units differs by a factor of 1000, and the symptoms are unmistakable:

This tool decides automatically: a value greater than or equal to 10¹² is treated as milliseconds, otherwise as seconds. There is an honest boundary to state: millisecond timestamps between 1970 and 2001 are smaller than 10¹², so this rule misclassifies them as seconds. If you process historical millisecond data from that window, convert it by hand — this is a fixed limitation of a heuristic threshold, not something tunable away.

Eight common bugs

1. Treating the time zone as part of the timestamp. A timestamp has no zone; it is just an instant. The classic "off by 8 hours" bug is really generating a timestamp from a local time as if it were UTC, or displaying a UTC timestamp as if it were local. For China (UTC+8) the symptom is exactly an 8-hour shift.
2. Months are zero-based. JavaScript's Date.getMonth() returns 0 for January, so December is 11. "The date is a month off" usually points here.
3. Inconsistent date-string parsing. new Date("2026-01-15") parses as UTC (ISO form is treated as UTC), while new Date("2026/01/15") parses in the local zone. The same calendar date, two notations, can differ by 8 hours and cross a day boundary. Prefer explicit ISO format or a raw timestamp over trusting the parser default.
4. Storing seconds in a 32-bit field. See the 2038 problem above.
5. Floating-point precision loss. Storing a second-level timestamp as a float keeps fractional milliseconds, but precision degrades as the number grows. For millisecond accuracy use integer milliseconds.
6. Mixing local and UTC in one column. A field that holds both UTC and hand-entered local values will sort and compare incorrectly. Store UTC in the database; convert only at display time.
7. Daylight-saving duplication or gaps. In DST regions a given 02:00 may occur twice or not at all. UTC storage sidesteps this. China has no DST, but any system serving overseas users will hit it.
8. Storing a date-only value as a timestamp. A birthday or billing day is a "date" semantic; converting it to a timestamp can roll it to the previous day when read in another zone. Use a date type, not a timestamp, for date-only values.

Practical conversion reference

Cache expiries, rate-limit windows, and session lifetimes all derive from these numbers. Note that 31,536,000 versus 31,557,600 differs by about 0.07% — negligible usually, but it compounds in yearly billing scenarios.

How to use the tool

• Timestamp → date: enter seconds or milliseconds (auto-detected), then toggle UTC or local time zone to inspect the result. The same instant displays differently per zone but points to the identical moment.
• Date → timestamp: enter a value in YYYY-MM-DD HH:mm:ss format to get the corresponding timestamp.
• A live current timestamp sits at the top of the page, useful for checking the skew between a server and your local machine.

All computation runs locally in the browser. Timestamps rarely carry sensitive data, but for business-validation work local processing is still the safer default.