How to Read and Convert Unix Timestamps (and Write Cron Correctly)

1719849600 is a date. So is 1719849600000. They are the same moment, expressed in two different units, and telling them apart is behind more logging bugs, off-by-a-thousand-fold errors, and “why is this event in 1970” incidents than almost anything else in software.

A Unix timestamp — also called epoch time or POSIX time — counts the seconds elapsed since 00:00:00 UTC on 1 January 1970. That is the whole concept. Everything confusing about it follows from two details: the unit, and the timezone.

Why a count of seconds instead of a date

Because a date is ambiguous and a number is not.

“March 15, 2026 at 2:30 PM” means different instants depending on where you are standing, and it becomes meaningless across a daylight-saving boundary. A stored timestamp has no such problem: it is a single integer, identical on every machine, in every timezone, forever. Store the number; format it for display on the way out. That is the rule, and breaking it — storing a formatted local date string — is how databases end up with events that shift by an hour twice a year.

Seconds or milliseconds: the bug that keeps happening

The same instant, in both units:

• Seconds: 1719849600 — 10 digits
• Milliseconds: 1719849600000 — 13 digits

JavaScript’s Date.now() returns milliseconds. Unix and most command-line tools work in seconds. The moment you mix them, you get one of two failures:

• Pass seconds where milliseconds are expected, and every date collapses to January 1970, because 1.7 billion milliseconds is only about 20 days after the epoch.
• Pass milliseconds where seconds are expected, and your event lands in the year 56000-something.

The digit-count rule is the fastest way to tell them apart: 10 digits is seconds, 13 is milliseconds, and anything else needs a closer look. The timestamp converter applies this automatically and, when the length is ambiguous, shows both interpretations side by side so you cannot silently pick the wrong one.

Timezones: the timestamp has none

Here is the fact that resolves most confusion: a Unix timestamp is always UTC. It carries no timezone, because it does not need one — it is a count, and counting is the same everywhere.

Timezone only enters the picture when you render the timestamp as a human-readable date. 1719849600 is simultaneously:

• 2026-07-01 16:00 in New York (EDT, UTC−4)
• 2026-07-01 21:00 in London (BST, UTC+1)
• 2026-07-02 05:00 in Tokyo (JST, UTC+9)

Same number. Three correct answers. This is why a log line that says “16:00” is useless without a timezone, and why every serious logging system stores UTC and converts at the edge. The converter shows your local time and UTC next to each other for exactly this reason — so you stop guessing which one you are looking at.

The 2038 problem, briefly

Timestamps stored as a signed 32-bit integer overflow on 19 January 2038, at 03:14:07 UTC. At that instant they wrap to a large negative number, and the date jumps to 1901.

It is not a crisis, because modern systems use 64-bit integers or floating point, and a 64-bit count of seconds will not overflow for about 292 billion years. But you will still meet 32-bit timestamps in old database columns, embedded devices, and file formats from the 1990s. If you are designing a schema today, store 64-bit — it costs nothing and removes the question permanently.

Converting a timestamp

1. Open the Unix timestamp converter.
2. Paste a timestamp, or use the live clock for “now”.
3. Read the result in your local timezone and UTC, side by side.
4. Going the other way, pick a date and time and read back the epoch value.

Everything runs locally in the page, which is worth noting for one reason: timestamps in logs tend to sit next to tokens, session IDs, and user identifiers. Pasting a block of that into a random website is a habit worth breaking.

Writing cron expressions that do what you meant

A cron expression is five fields, in this order:

minute  hour  day-of-month  month  day-of-week
  *       *         *          *         *

So 0 */6 * * 1-5 reads as: at minute 0, every 6th hour, on any day of the month, in any month, when the day of the week is Monday through Friday. The cron parser translates that into plain language and shows the next ten run times, which is the only reliable way to confirm you wrote what you intended.

Four things that catch people:

The timezone is the server’s, not yours. Cron runs in whatever timezone the machine is set to. A job you wrote to run “at 9 AM” runs at 9 AM UTC on a UTC server — which is 4 AM in New York. This single misunderstanding sits behind a large share of “why did my job run at the wrong time” questions. Check the server’s timezone before you trust the hour field.

Day-of-month and day-of-week are ORed, not ANDed. This is the most famous cron gotcha. When both fields are restricted — say 0 0 13 * 5 — the job runs on the 13th of the month or on any Friday, not on Friday the 13th. If you want the intersection, you cannot express it in a single expression.

*/15 is not “every 15 minutes past the hour” in the way people assume. It is every 15 minutes, all hour long: :00, :15, :30, :45. That is usually what people want, but it is worth being explicit about.

0 and 7 both mean Sunday in the day-of-week field. Standard cron accepts both. Pick one and stay consistent.

Frequently asked questions

How do I tell a seconds timestamp from a milliseconds one? Count the digits. 10 digits is seconds, 13 is milliseconds. 1.7 billion is a plausible seconds value; 1.7 trillion is a plausible milliseconds value.

Why does my timestamp show 1970? Almost always a units mismatch. Seconds were interpreted as milliseconds, so the value corresponds to a few days after the epoch rather than to the present.

What timezone is a Unix timestamp in? None — it is UTC by definition. Timezones only appear when you format it for display.

Why did my cron job run at the wrong hour? Because cron uses the server’s timezone. Convert your intended local time to the server’s timezone, or set the server’s TZ explicitly.

What does 0 0 13 * 5 actually do? It runs at midnight on the 13th of the month, or on any Friday. Day-of-month and day-of-week are ORed, not ANDed, when both are restricted.