Unix timestamps: seconds, milliseconds and the wrong date

A timestamp that lands in January 1970 often has the wrong unit. The number 1792069200 is Unix seconds; 1792069200000 is the same instant in milliseconds. Neither needs you to add a timezone offset before converting it.

Open the Timezone converter, expand Paste a date or timestamp, paste either number and choose Convert. Check the interpretation beneath the form. Both should produce 2026-10-15T13:00:00.000Z.

Four ways to write the same moment

Try these one at a time, or download the four timestamp examples:

1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00

The last line is already midnight on the next day, but it still represents the same moment. Its explicit eleven-hour offset accounts for the difference.

The tool reads the first number as seconds and the second as milliseconds. For dates around today, 10 versus 13 digits is a useful clue, not a universal definition of a timestamp. This converter rejects 11- and 12-digit numeric inputs instead of guessing. It supports dates from 1900 through 2100; it is not a parser for every historical timestamp format.

If you are writing JavaScript, the numeric Date constructor expects milliseconds. MDN's Date reference documents that unit. Multiplying seconds by 1,000 is a unit conversion, not a timezone adjustment.

Check the date as well as the clock

Use Add timezone to include the cities you need. For the sample above, the tested results are:

These offsets belong to the sample date. Do not reuse them as permanent differences between cities; daylight saving can change the gap. For a recurring task, see the cron and daylight-saving example.

Dragging inside any clock card moves the shared moment, so every card updates together. Copy all times copies the dates and offsets too. That is more useful to a teammate than sending “9am” on its own.

A date without an offset is a different input

Paste 2026-10-15T13:00 and set Without a timezone, read as to Australia/Melbourne. It becomes 2026-10-15T02:00:00.000Z, eleven hours earlier than our first example.

Nothing broke: this time you supplied a local clock reading, and the source timezone supplied the missing context. With a Unix number or an explicit offset, that source selection does not move the instant. My timezone can add your device's zone, but your device cannot tell you which timezone an unlabelled log entry originally used.

Resolve ambiguous input before sharing it

The tool deliberately asks you to clarify several inputs:

• 10/11/2026 09:00 could mean October 11 or November 10. Use a year-month-day date.
• 2026-10-15 09:00 CST uses an ambiguous abbreviation. Choose a full source timezone or supply an explicit UTC offset.
• 2026-11-01T01:30 in America/New_York occurs twice when clocks go back. Supply the intended offset; a local clock reading alone cannot choose between them.

We checked these inputs and the four equivalent timestamps against the tool's parser on 15 October 2026. The conversion output and results record preserve the exact values. Natural-language parsing varies by language; an explicit date and offset is the better choice when the time must be unambiguous.