How to Convert a Unix Timestamp:
Step-by-Step Tutorial

This tutorial shows you how to convert a Unix timestamp like 1784536442 into a human-readable date, and how to go the other way. It takes under a minute, including the one check that prevents the most common mistake: confusing seconds with milliseconds.

Step 1: Check Whether It's Seconds or Milliseconds

Before converting, count the digits. This single check prevents dates that are off by decades:

• 10 digits (e.g. 1784536442) — seconds. The Unix standard, used by most APIs, databases, and Python's time.time().
• 13 digits (e.g. 1784536442000) — milliseconds. JavaScript's native unit (Date.now()), also Java's.
• 16 digits — microseconds (some databases and logging systems).
• 19 digits — nanoseconds (Go's UnixNano(), some metrics systems).

If you feed a milliseconds value into a seconds-based converter, you'll get a date around the year 58,000. If you feed seconds into a milliseconds-based one, you'll get January 1970. Both mean unit mismatch, not data corruption.

Step 2: Convert Timestamp to Date

Open the Timestamp Converter and paste the value. The tool detects seconds vs milliseconds automatically and shows the result in both UTC and your local timezone:

Input:  1784536442
UTC:    2026-07-20 06:34:02 UTC
Local:  2026-07-20 14:34:02 GMT+8

Read the UTC line when comparing against server logs (servers should log in UTC), and the local line when relating the event to your own clock. The difference between the two lines is exactly your timezone offset — if that offset looks wrong, your OS timezone setting is the problem, not the timestamp.

Step 3: Convert a Date to a Timestamp

Going the other way — you have "July 20, 2026 at 14:34" and need the epoch value — enter the date and time in the tool's date-to-timestamp section. One critical detail: specify which timezone the date is in. "2026-07-20 14:34" is ambiguous; it maps to a different timestamp for every timezone. The timestamp itself has no timezone (it's always seconds since 1970-01-01 00:00:00 UTC), but the wall-clock date you start from does.

Typical uses: setting a token expiry in a config file, writing a test fixture that needs a fixed date, or crafting a database query range by hand.

Worked Example: Investigating a Log Entry

A monitoring alert says an error spike started at 1784530000. The workflow:

1. 10 digits → seconds. Paste into the converter: 2026-07-20 04:46:40 UTC.
2. Your deploy log (in local time, GMT+8) shows a release at 12:40. Convert: 12:40 GMT+8 = 04:40 UTC.
3. The error spike began 6 minutes and 40 seconds after the deploy. Now you have a correlation worth investigating — and both times are on the same axis, which is the entire point of converting everything to UTC before comparing.

When you need to compare times across several timezones at once (a deploy in Berlin, logs in UTC, users complaining from California), the Timezone Converter handles the multi-zone view.

Converting Timestamps Without the Tool

# Linux (GNU date)
date -d @1784536442
# → Mon Jul 20 06:34:02 UTC 2026

# macOS (BSD date)
date -r 1784536442

# Current timestamp, any Unix system
date +%s

# JavaScript — note the ×1000 for seconds input
new Date(1784536442 * 1000).toISOString()
// → "2026-07-20T06:34:02.000Z"
Math.floor(Date.now() / 1000)   // current time in seconds

# Python
python3 -c "from datetime import datetime, timezone; print(datetime.fromtimestamp(1784536442, tz=timezone.utc))"

The macOS/Linux flag difference (-r vs -d @) is a perennial gotcha in shell scripts meant to run on both. In JavaScript, forgetting the * 1000 is the classic bug — new Date(1784536442) silently interprets the value as milliseconds and gives you January 21, 1970.

Common Problems and Fixes

The converted date is January 1970

Your value was interpreted as milliseconds but is actually seconds (or the value is tiny/zero). Multiply by 1000 in JavaScript contexts, or check whether the source field was null — many systems serialize missing dates as 0, which is exactly 1970-01-01T00:00:00Z.

The date is off by exactly a few hours

Timezone display issue, not a wrong timestamp. The timestamp is timezone-less; only the rendering differs. Confirm by converting to UTC in both systems and comparing — if the UTC values match, both systems agree and one of them is just displaying in a different zone.

The date is off by one hour, but only for some dates

Daylight saving time. A timezone's UTC offset changes during the year (e.g. New York is UTC-5 in January, UTC-4 in July). If your code applies a fixed offset instead of a named timezone like America/New_York, dates in the "other half" of the year come out an hour off. The timezone guide covers DST handling in detail.

Negative timestamp

Valid — it's a date before 1970. -86400 is December 31, 1969. Some tools and languages handle negatives poorly, so if you work with historical dates, test that path explicitly.

Timestamps stop working in 2038?

Only on systems storing them as signed 32-bit integers, which overflow on January 19, 2038 at 03:14:07 UTC. Modern 64-bit systems and languages are unaffected. If you maintain embedded systems or legacy databases with 32-bit time fields, that migration is real; otherwise it's trivia.

FAQ

What exactly is a Unix timestamp?

The number of seconds elapsed since 1970-01-01 00:00:00 UTC (the "epoch"), ignoring leap seconds. It's the lingua franca of machine time: a single integer, no timezone ambiguity, trivially sortable and subtractable. The Unix timestamps guide covers the history and design in depth.

Why do APIs use timestamps instead of readable dates?

Comparing and sorting integers is fast and unambiguous. "03/04/2026" is March 4 in the US and April 3 in most of Europe; 1772668800 is the same moment everywhere. Store and transmit timestamps (or ISO 8601 UTC strings); format to local time only at the display layer.

Should I store timestamps or datetime strings in my database?

Either works if you're disciplined about UTC. Native timestamp/datetime columns (stored internally as UTC) give you date arithmetic and indexing; integer epoch columns are portable and unambiguous. The one wrong answer is storing local wall-clock strings without timezone info — those become unrecoverable once DST or a server move enters the picture.

How precise are Unix timestamps?

The classic form is whole seconds. Milliseconds (13 digits) are standard in JavaScript and Java; micro- and nanoseconds appear in databases and tracing systems. Precision beyond milliseconds rarely survives network transport — NTP-synced clocks on different machines typically agree only to within a few milliseconds anyway.