Search DevTools

Jump to any tool or page

Unix Timestamp Converter

Convert a Unix timestamp to a date, or a date back to a timestamp. Adjust the time zone, adjust by an interval, and read off every common format.

Input

seconds or milliseconds

Placeholders: yyyy, MM, dd, HH, mm, ss

Adds or subtracts the amount from the current result.

Results

Resolving the current time…

Developer Utilities

About Unix Timestamp Converter

Convert between Unix epoch values and human-readable dates in UTC or local time, in either seconds or milliseconds. Unix time counts seconds since 1970-01-01T00:00:00Z while deliberately ignoring leap seconds, which makes it a smooth arithmetic scale rather than a true count of elapsed SI seconds — a property that keeps date maths simple and makes precise interval measurement subtly wrong.

Related Developer Utilities tools

Token CounterZod GeneratorBase64 Encoder/DecoderSecret ScannerHash Generator

Frequently asked questions

Seconds or milliseconds — how do I tell which I have?
By magnitude. A present-day timestamp in seconds is ten digits, around 1.7 billion; in milliseconds it is thirteen, around 1.7 trillion. The classic bug is feeding seconds to JavaScript's Date constructor, which expects milliseconds and cheerfully returns a date in early 1970, or feeding milliseconds to a Python or Go API expecting seconds and landing somewhere around the year 55000. Multiply or divide by 1000 at the boundary, and prefer an explicit unit in field names — expires_at_ms beats expires_at.
What is the 2038 problem, and is it still relevant?
A signed 32-bit time_t overflows at 03:14:07 UTC on 19 January 2038, wrapping to December 1901. Most 64-bit systems are fine, but the exposure survives in 32-bit embedded firmware, in database columns declared as a 4-byte integer, and in MySQL's TIMESTAMP type, which is bounded at 2038-01-19 regardless of the host architecture. It bites early too: any code computing a thirty-year expiry already overflows today. Use a 64-bit integer or a DATETIME column, and test with dates past 2038.
Why can Unix time not measure a precise interval?
Because it pretends leap seconds do not exist. Since 1972 there have been 27 of them, and each is absorbed rather than counted — POSIX systems typically repeat or smear the value across the insertion, so the difference between two timestamps a decade apart is short by 27 real seconds. It also means a timestamp can be ambiguous or non-monotonic across a leap second. For durations that must be exact, use a monotonic clock; for wall-clock display, Unix time is exactly right.
What is the difference between UTC and local rendering of the same value?
None at all in the stored number — an epoch value is an absolute instant with no timezone attached. The timezone applies only at formatting. This is why the same timestamp reads as two different dates for two users, and why a bug reported as "the date is off by one day" is usually a UTC-rendered value being read in a negative-offset zone near midnight. Store and transmit UTC epoch or an ISO 8601 string with an explicit offset; convert only in the presentation layer.
How should I handle negative timestamps and sub-second precision?
Negative values are legitimate and represent instants before 1970 — useful for dates of birth, historical records and the like. Some parsers reject them or treat the field as unsigned, so validate before assuming. On precision: seconds and milliseconds are the common wire formats, but microseconds appear in Postgres and Python's datetime, and nanoseconds in Go's UnixNano and in Prometheus. Nanosecond values exceed the 2^53 safe-integer limit in JavaScript, so parse them as strings or BigInt rather than as JSON numbers.