HandyBench

Unix Timestamp Converter

Convert epoch timestamps to dates and back.

How to use the Unix Timestamp Converter

  1. 1 Paste a Unix timestamp, or pick a date and time.
  2. 2 See it converted in both UTC and your local timezone.
  3. 3 Copy the value you need.

What a Unix timestamp counts

Unix time is the number of seconds since 00:00:00 UTC on 1 January 1970, called the epoch, ignoring leap seconds. It has no time zone: one number names one instant everywhere, and zones only appear when you display it. JavaScript's Date counts in milliseconds, which is why you meet both 10-digit and 13-digit values.

Worked example

Entering 1700000000 gives:

FieldValue
UTCTue, 14 Nov 2023 22:13:20 GMT
ISO 86012023-11-14T22:13:20.000Z
LocalThe same instant in your browser's time zone and locale format

Entering the 13-digit 1700000000000 gives the identical result. In the other direction, a date picked as 29 Feb 2024 12:00 is read as local time. If your computer is set to UTC, it converts to 1709208000 seconds or 1709208000000 milliseconds, and in any other zone you get a different number.

How seconds and milliseconds are told apart

There is no switch for this. The rule uses the digits before any decimal point: ten digits or fewer is treated as seconds, and anything longer is taken as milliseconds. The result is labelled "Read as seconds" or "Read as milliseconds" so you can check. That works for any date between September 2001 and November 2286. The rule has a few side effects.

  • A decimal like 1700000000.5 is read as seconds with half a second added, because only the digits before the point are counted. The ISO result shows .500Z.
  • An 11-digit number is treated as milliseconds, so it lands between 1970 and 1973 rather than in the far future.
  • A negative timestamp counts back from the epoch: -1 is 23:59:59 UTC on 31 December 1969.
  • Text that is not a number, such as abc or 12:30, shows an error message, as does a value too large for JavaScript dates.

Handy reference values

SecondsMoment (UTC)
01970-01-01 00:00:00
10000000002001-09-09 01:46:40
21474836472038-01-19 03:14:07, the limit of a signed 32-bit integer

Systems that store seconds in 32 bits overflow one second later, the so-called Year 2038 problem, while 64-bit values last for billions of years. "Use now" fills in the current time in seconds. For the gap between two dates, use date difference, and to compare clock times across cities, the time zone converter.

Examples

  • ▸ 1700000000 is Tue, 14 Nov 2023 22:13:20 UTC (2023-11-14T22:13:20.000Z).
  • ▸ 1700000000000 gives the identical date, because 13 digits are read as milliseconds.
  • ▸ Typing abc or 12:30 shows a clear error instead of a blank result.
  • ▸ Picking 29 Feb 2024 12:00 on a UTC computer gives 1709208000 seconds.

Frequently asked questions

What is a Unix timestamp?

It is the number of seconds (or milliseconds) elapsed since 1 January 1970 UTC, a common way to store time in databases and APIs.

Does it handle milliseconds?

Yes, automatically. If the part before any decimal point has 10 digits or fewer it is read as seconds, and anything longer as milliseconds. The result is labelled "Read as seconds" or "Read as milliseconds", and the date-to-timestamp side shows both.

Is the date I pick treated as UTC or local time?

Local time. The date and time picker uses your browser time zone, so the same wall-clock time gives a different timestamp in New York than in London. The timestamp-to-date side shows both UTC and local results.

What is the Year 2038 problem?

Systems that store Unix seconds in a signed 32-bit integer run out at 2147483647, which is 03:14:07 UTC on 19 January 2038. Values stored in 64 bits are not affected.

Why does my timestamp show a date in 1970?

Usually the value is in the wrong unit. A seconds value that is far too small, or milliseconds with digits missing, lands in 1970. Decimals are fine: 1700000000.5 is read as seconds plus half a second. Count the digits before the decimal point, and check which unit the result says it was read as.