Skip to main content

Unix Timestamp Converter

Convert between Unix epoch seconds/milliseconds, ISO 8601, RFC 2822 and local/UTC times.

Now
Epoch (sec)
Epoch (ms)
ISO 8601
RFC 2822
Local time
UTC
Weekday
Day of year

About this tool

Unix Timestamp Converter is a quick way to translate between Unix epoch seconds / milliseconds, ISO 8601 strings, RFC 2822 strings, and your local / UTC clocks. It also surfaces weekday and ISO week / day-of-year, which saves a Python or “date +%V” callout.

Three input tabs

  • Timestamp — paste an epoch number; we auto-detect seconds vs. milliseconds by magnitude (> 10¹² is treated as ms).
  • ISO 8601 — paste any ISO string including timezone offsets (“2024-01-01T00:00:00+09:00”).
  • Date / time — a datetime-local picker; choose UTC or local-zone interpretation.

What the inputs mean

  • Epoch seconds are the classic Linux/Unix form: seconds since 1970-01-01 00:00:00 UTC. What date +%s prints.
  • Epoch milliseconds are the JavaScript form (Date.now()).
  • ISO 8601 is what JSON.stringify(new Date()) produces, and what most REST APIs accept.
  • RFC 2822 is what email headers use, “Tue, 18 Jun 2024 12:00:00 GMT”.
  • Local is your browser’s timezone.
  • UTC is the timezone-free reference.

Limits and gotchas

  • Browsers only support millisecond precision for Date, so sub-millisecond timestamps (used in some databases) will be silently rounded.
  • Negative timestamps before 1970 work fine — just paste the number.
  • Daylight-saving boundaries can give you a 1-hour jump: this is real wall-clock time, not a bug.

Privacy

Everything runs in your browser. No network.

Common use cases

  • Reading server logs. Paste an epoch value from an application log or access log line to see the exact calendar date, weekday, and UTC time of the event.
  • Checking token expiry. JWT exp claims and most API credentials are expressed in Unix seconds; converting one tells you precisely when it stops working.
  • Verifying scheduled jobs. Confirm that a cron trigger or a delayed task computed the right moment by converting its target epoch to your local timezone.
  • Comparing database columns. Mixed schemas often store some times in seconds and others in milliseconds; the side-by-side fields make the two conventions directly comparable.
  • Building API signatures. Grab the current epoch from the Now card when a request signature or cache-busting parameter calls for one.

How to use

  1. The Now card at the top shows the current Unix time in seconds together with the full date string, which ticks every second. Press the refresh button to re-snapshot the moment into the whole page.
  2. Pick an input tab: Timestamp for raw epoch values, ISO 8601 for strings such as 2024-06-18T12:00:00Z, or Date for a calendar picker.
  3. In the Timestamp tab, type into either the seconds or the milliseconds field; each has its own box so the units can never be confused.
  4. In the Date tab, set the date and time, then choose whether to interpret it in your local timezone or in UTC.
  5. Every output card updates together as one consistent moment: epoch seconds, epoch milliseconds, ISO 8601, RFC 2822, local time, UTC time, weekday, and day of year with its ISO week number.
  6. Click the copy icon on any card to copy that single representation to your clipboard.

Tips and pitfalls

The seconds-versus-milliseconds mix-up is the classic timestamp bug. A ten-digit value is seconds in the present era and a thirteen-digit value is milliseconds; feed one into a function expecting the other and you silently get a date near 1970 or tens of millennia in the future. This converter keeps the two in separate fields and floors milliseconds to whole seconds internally, so the page always describes one coherent moment at second precision.

Two properties of Unix time surprise people. First, it ignores leap seconds: every day is treated as exactly 86400 seconds, which keeps conversion pure arithmetic but means Unix time drifts from the true SI-second count. Second, the Year 2038 problem: systems storing epoch seconds in a signed 32-bit integer overflow at 2147483647 (2038-01-19 03:14:07 UTC) and wrap to December 1901. JavaScript Date values are 64-bit milliseconds with a range of roughly plus or minus 275,760 years, so nothing here overflows, but the APIs and embedded devices you integrate with may still be 32-bit.

Timezones are a display concern, not a storage one. An epoch identifies a single absolute instant everywhere on Earth; only the human-readable rendering differs by zone. That is why the ISO input matters: a string ending in Z pins the instant to UTC, while a bare datetime with no offset is parsed as your browser’s local time. When in doubt, use the Date tab and pick Local or UTC explicitly rather than relying on string conventions.

FAQ

How do I tell whether a timestamp is in seconds or milliseconds?

Count the digits for any contemporary date: Unix seconds are currently ten digits (about 1.7 billion) while milliseconds are thirteen. If a value in seconds is mistakenly treated as milliseconds the date lands tens of thousands of years in the future, and the reverse misreading lands near 1970. This tool gives the two units separate input fields so the ambiguity disappears.

What is the Year 2038 problem?

Systems that store Unix time in a signed 32-bit integer overflow at 2147483647, which is 2038-01-19 03:14:07 UTC; the next second wraps around to a date in December 1901. JavaScript Date values use a 64-bit millisecond count with a range of roughly plus or minus 275,760 years, so the conversions on this page are unaffected, but embedded systems and old databases still carry the limit.

Does Unix time count leap seconds?

No. Unix time is defined as if every day had exactly 86400 seconds, so the leap seconds inserted into UTC since 1970 are not represented. A positive consequence is that converting between a timestamp and a calendar date is pure arithmetic with no lookup table; the cost is that Unix time can differ from the true count of elapsed SI seconds.

Why does my ISO string convert to a different hour than I expected?

A string ending in Z or carrying an explicit offset is interpreted in UTC terms, but a bare datetime such as 2024-06-18T12:00:00 with no suffix is parsed as local time in your browser timezone. Use the Date tab with its Local/UTC selector when you want to control the interpretation explicitly instead of relying on the string format.

What timezone does the Local output use?

It uses the timezone reported by your browser through the Intl API, which normally follows your operating system setting, and the same zone is shown next to the Local option in the Date tab selector. The UTC output card is always rendered in UTC regardless of that setting.

Can I convert a date before 1970?

Pre-epoch dates have negative Unix timestamps, which is perfectly valid. The numeric seconds and milliseconds fields on this page accept positive values only, but you can inspect a pre-1970 moment by pasting it into the ISO 8601 input, for example 1950-01-01T00:00:00Z, and the full output grid will follow.