How to fix: Timestamp in milliseconds treated as seconds

JavaScript `Date.now()` returns milliseconds. Unix timestamps are typically seconds. Passing ms to a seconds-based converter gives a date 1000x in the future. Fix: 1. Check the timestamp length: 10 digits = seconds, 13 digits = milliseconds. 2. Divide millisecond timestamps by 1000 before converting to seconds. 3. Use the 'milliseconds' mode in the converter for JS timestamps.

How to fix: Date is off by hours (timezone error)

Unix timestamps are always UTC. Converting without specifying timezone or using local time instead of UTC introduces offset errors. Fix: 1. Use the converter's UTC output — it's always unambiguous. 2. Specify timezone explicitly when formatting: `new Date(ts).toLocaleString('en-US', {timeZone: 'UTC'})`. 3. Store and transmit timestamps in UTC; convert to local time only for display.

How to fix: Time changes by 1 hour around DST transition

Local time has DST transitions — 1 AM becomes 2 AM (spring) or 2 AM becomes 1 AM (fall). Arithmetic on local time breaks around these transitions. Fix: 1. Always do date arithmetic in UTC: convert to UTC, add intervals, convert back. 2. Use a date library (date-fns, Luxon) that handles DST correctly. 3. For cron-like scheduling, use UTC-based cron expressions.

How to fix: Timestamp overflows (Year 2038 problem)

32-bit signed integers can only hold Unix timestamps up to January 19, 2038. Systems using 32-bit time_t overflow to negative values (year 1901). Fix: 1. Use 64-bit integers for timestamp storage (int64, bigint). 2. In MySQL, use BIGINT or DATETIME (> 2038) instead of TIMESTAMP columns. 3. In Python, use `int` (arbitrary precision) not `ctypes.c_int32`. 4. Verify with the timestamp converter: year > 2038 should show correctly.

How to fix: Negative timestamp causes invalid date

Negative Unix timestamps represent dates before January 1, 1970 (Unix epoch). Many date libraries do not support pre-epoch dates correctly. Fix: 1. Check if your timestamp is expected to be before 1970. 2. The converter handles negative timestamps — verify the output date makes sense. 3. For pre-1970 dates, use a full-featured date library like Luxon.

Date & Time 2026-03-10

Fix Unix Timestamp Conversion Errors

Fix off-by-one-hour errors, milliseconds vs seconds confusion, timezone mismatches, and year 2038 timestamp issues.

⏱️ Tool: Timestamp Converter — Free

Unix timestamps look simple but hide subtle bugs around timezone handling, milliseconds vs seconds precision, and platform differences. Here are the six most common timestamp conversion mistakes.

Jump to error

1 Timestamp in milliseconds treated as seconds
2 Date is off by hours (timezone error)
3 Time changes by 1 hour around DST transition
4 Timestamp overflows (Year 2038 problem)
5 Negative timestamp causes invalid date

Timestamp in milliseconds treated as seconds

Error message

Date shows year 2554 or similar far-future date

Root cause

JavaScript `Date.now()` returns milliseconds. Unix timestamps are typically seconds. Passing ms to a seconds-based converter gives a date 1000x in the future.

Step-by-step fix

1 Check the timestamp length: 10 digits = seconds, 13 digits = milliseconds.
2 Divide millisecond timestamps by 1000 before converting to seconds.
3 Use the 'milliseconds' mode in the converter for JS timestamps.

Wrong

// JS timestamp in ms treated as seconds:
new Date(1710000000000)  // Correct
new Date(1710000000)     // 50 years ago!

Correct

// Always check precision:
const tsMs = Date.now();           // 13 digits
const tsSec = Math.floor(tsMs / 1000); // 10 digits

Date is off by hours (timezone error)

Error message

Timestamp converts to wrong time — off by 1-12 hours

Root cause

Unix timestamps are always UTC. Converting without specifying timezone or using local time instead of UTC introduces offset errors.

Step-by-step fix

1 Use the converter's UTC output — it's always unambiguous.
2 Specify timezone explicitly when formatting: `new Date(ts).toLocaleString('en-US', {timeZone: 'UTC'})`.
3 Store and transmit timestamps in UTC; convert to local time only for display.

Wrong

// Assumes local timezone — wrong for users in other TZs:
const date = new Date(timestamp);
return `${date.getMonth() + 1}/${date.getDate()}`;

Correct

// Explicit UTC:
const date = new Date(timestamp);
return date.toISOString().split('T')[0];  // YYYY-MM-DD in UTC

Time changes by 1 hour around DST transition

Error message

Schedule fires at wrong time on daylight saving transition days

Root cause

Local time has DST transitions — 1 AM becomes 2 AM (spring) or 2 AM becomes 1 AM (fall). Arithmetic on local time breaks around these transitions.

Step-by-step fix

1 Always do date arithmetic in UTC: convert to UTC, add intervals, convert back.
2 Use a date library (date-fns, Luxon) that handles DST correctly.
3 For cron-like scheduling, use UTC-based cron expressions.

Wrong

// Adding 24h in local time — wrong on DST day:
const tomorrow = new Date(date);
tomorrow.setHours(date.getHours() + 24);

Correct

// Add 24h in UTC:
const tomorrow = new Date(date.getTime() + 24 * 60 * 60 * 1000);

Timestamp overflows (Year 2038 problem)

Error message

Date shows 1901 or 2038 on 32-bit systems

Root cause

32-bit signed integers can only hold Unix timestamps up to January 19, 2038. Systems using 32-bit time_t overflow to negative values (year 1901).

Step-by-step fix

1 Use 64-bit integers for timestamp storage (int64, bigint).
2 In MySQL, use BIGINT or DATETIME (> 2038) instead of TIMESTAMP columns.
3 In Python, use `int` (arbitrary precision) not `ctypes.c_int32`.
4 Verify with the timestamp converter: year > 2038 should show correctly.

Wrong

// 32-bit C: overflows in 2038:
time_t ts = (int32_t)time(NULL);

Correct

// 64-bit: safe for billions of years:
int64_t ts = (int64_t)time(NULL);

Negative timestamp causes invalid date

Error message

Invalid Date returned from new Date(-1)

Root cause

Negative Unix timestamps represent dates before January 1, 1970 (Unix epoch). Many date libraries do not support pre-epoch dates correctly.

Step-by-step fix

1 Check if your timestamp is expected to be before 1970.
2 The converter handles negative timestamps — verify the output date makes sense.
3 For pre-1970 dates, use a full-featured date library like Luxon.

Wrong

// Assumes timestamps are always positive:
if (timestamp > 0) { ... } else { return 'Invalid'; }

Correct

// Negative timestamps are valid (pre-1970):
const date = new Date(timestamp * 1000);
if (!isNaN(date.getTime())) { ... }

Frequently Asked Questions

What is the Unix epoch?

The Unix epoch is January 1, 1970, 00:00:00 UTC. Unix timestamps count the number of seconds (or milliseconds) since this moment.

Why do APIs sometimes return timestamps with decimal points?

Sub-second precision. `1710000000.123` means 123 milliseconds past the second. Some APIs use nanoseconds (16+ digits). Check the API documentation for the precision used.

Related Tools

{ }

JSON Formatter

Format, minify & validate JSON

Compare texts & find differences

Try the Timestamp Converter now

Free, runs in your browser, no signup required. Learn more about Timestamp Converter.

Open Timestamp Converter →

← All Troubleshooting Guides