Free Unix Timestamp Generator

How It Works

1. Convert a date to timestamp: Enter any date and time using the date picker, then click Convert to get the Unix timestamp in seconds and milliseconds.
2. Convert a timestamp to date: Paste a Unix timestamp (seconds or milliseconds) to convert it back to a human-readable date and time.
3. Get the current timestamp: Click "Now" to instantly get the current Unix timestamp for the present moment.

Why Use Unix Timestamp Generator?

Unix timestamps are the universal language of time in computing, a single integer representing seconds since January 1, 1970 (UTC). They power databases, APIs, log files, authentication tokens, and event scheduling. Converting between Unix timestamps and human-readable dates manually involves complex timezone arithmetic that is easy to get wrong. This tool handles the conversion correctly in both directions, saving time and preventing timezone bugs.

Features

• Bidirectional conversion: Date/time → Unix timestamp and Unix timestamp → date/time.
• Seconds and milliseconds: Supports both Unix time in seconds (10 digits) and milliseconds (13 digits).
• Timezone awareness: Displays the time in your local timezone and in UTC for unambiguous comparison.
• Current time button: Instantly grab the timestamp for right now.
• Relative time display: Shows how long ago or how far in the future a timestamp is (e.g., "3 days ago").

Frequently Asked Questions

What is a Unix timestamp?

A Unix timestamp is the number of seconds elapsed since the Unix epoch, midnight UTC on January 1, 1970. It is a timezone-independent representation of a point in time, making it the preferred format for storing and comparing times in databases and APIs.

Why does JavaScript use milliseconds?

JavaScript's Date.now() and new Date().getTime() return milliseconds since the epoch (a 13-digit number), while Unix tools and most databases use seconds (a 10-digit number). Check whether your timestamp has 10 or 13 digits to determine which format you have.

How do I convert a timestamp to my local time?

Paste the timestamp and the tool automatically converts it to your browser's local timezone. The display shows both local time and UTC so you can work across timezones confidently.

Where Unix time comes from

Unix time was defined by Ken Thompson and Dennis Ritchie in Unix First Edition (November 1971). Initially the kernel counted 60ths of a second since 1971-01-01 in a 32-bit field, which overflowed after 2 years 9 months. By Unix Sixth Edition (1975) the count had been changed to seconds since 1970-01-01 00:00:00 UTC, the epoch every Unix-like system still uses today. The choice was arbitrary, the engineers needed a round date close to the era they were working in. POSIX.1 (1988) codified the definition as the official standard, and POSIX.1-2017 (IEEE Std 1003.1-2017), the current version, still defines time_t as the number of seconds since the epoch, with the caveat that POSIX time pretends leap seconds don't exist. ISO 8601 (1988, currently 2019) standardised the human-readable format 2026-05-13T14:30:00Z, and RFC 3339 (July 2002) narrowed it to an unambiguous internet date-time profile. JavaScript's Date.now() returns milliseconds since the epoch because the spec was written in 1995 when sub-second precision was already in demand; most databases and Unix utilities still use whole seconds.

The Year 2038 problem (and why it matters now)

A signed 32-bit time_t can represent at most 2,147,483,647 seconds, which arrives at 03:14:07 UTC on Tuesday, 19 January 2038. One second later, the counter wraps to −2,147,483,648, which most software interprets as 13 December 1901. This is the same class of bug as Y2K but caused by integer width, not date format. The fix is to use 64-bit time_t (which pushes the wraparound to roughly the year 292 billion). Most 64-bit Linux systems already use 64-bit time_t by default; Linux 5.6 (March 2020) made 64-bit time_t available on 32-bit architectures too. The remaining risk lives in embedded systems, old binary file formats, and 32-bit network protocols. The Network Time Protocol (NTP) already wraps in 2036 because it uses an unsigned 32-bit count since 1900, NTPv4 adds an era number to extend it. If you ship software that handles dates, audit your stack before 2038, especially for SQL columns typed as INT(11) or older C code with long time fields.

The timestamp formats you will meet

• Unix seconds (10 digits). 1747143000. The classic POSIX time_t. Used by PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), Redis TTLs, JWT iat/exp claims (per RFC 7519), git log, and most Unix utilities. Will be 11 digits after November 2286.
• Unix milliseconds (13 digits). 1747143000000. JavaScript's Date.now(), Java's System.currentTimeMillis(), Kafka, Elasticsearch, and most modern logging pipelines. Times 1000 the second count.
• Unix microseconds (16 digits) and nanoseconds (19 digits). 1747143000000000. Used by Python's time.time_ns(), Go's time.Now().UnixNano(), etcd MVCC revisions, and high-frequency trading systems where millisecond resolution is too coarse.
• ISO 8601. 2026-05-13T14:30:00.000Z or 2026-05-13T14:30:00+02:00. Sortable as a string, unambiguous about timezone, accepted by virtually every modern API. The Z suffix means "Zulu time", a NATO designator for UTC.
• RFC 3339. A stricter profile of ISO 8601 used by JSON Schema, OpenAPI, and most REST APIs. Requires a timezone designator and disallows some ISO 8601 features like week dates and ordinal dates.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. The email Date: header format. Still ubiquitous because SMTP runs everywhere.
• Excel serial date. Fractional days since 1900-01-01 (or 1904 on classic Mac Excel). 2026-05-13 14:30 is approximately 46150.6042. Excel famously treats 1900 as a leap year (it isn't) for Lotus 1-2-3 compatibility.

When this tool earns its keep

• JWT debugging. Token has "exp": 1747143000 and you need to know if it's expired. Paste, see the human date.
• Log forensics. A line says timestamp=1747143012345, you need to correlate with another tool's wall-clock time. 13 digits, so milliseconds.
• Database queries. You want to find rows after a specific date. WHERE created_at > 1747143000 needs the seconds value; copy it from the tool.
• Test fixtures. Hard-coding "yesterday" in a test, you generate the timestamp now and paste it into the spec.
• Cron / scheduled jobs. Verify the seconds value a scheduler will fire at, especially across DST transitions.
• Event replay. Kafka offsets and Elasticsearch indices often use ms timestamps; convert to a date to inspect a specific replay window.
• Cache invalidation. An Expires header or If-Modified-Since in RFC 2822 format, generate the right wire format for testing.

Mistakes that cost teams hours

• Mixing seconds and milliseconds. Passing a 10-digit value to a function expecting milliseconds returns a date in 1970, off by a factor of 1000. The 10-vs-13-digit rule is the fastest test, modern values in seconds are 10 digits until 2286, in milliseconds 13 digits.
• Storing local time. Always store UTC; convert to local at display time. Storing "2026-05-13 14:30:00" without a timezone breaks the moment a server, user, or DST jump changes the local offset.
• Forgetting DST transitions. 2:30 AM happens twice during fall-back. Naive code that does start + (24 * 3600) to mean "tomorrow" will be off by an hour twice a year. Use a real date library (luxon, date-fns-tz, Python zoneinfo) that knows the IANA tz database.
• Assuming POSIX time accounts for leap seconds. It doesn't. 2016-12-31 23:59:60 existed in real life (the 27th leap second) but POSIX time_t jumps from 23:59:59 to 00:00:00 with no awareness of the extra second. TAI (International Atomic Time) does count leap seconds, POSIX time is offset from UTC by zero seconds.
• Storing time_t in INT(4) columns. Old MySQL schemas frequently use INT which is 4 bytes / signed 32-bit / wraps in 2038. Migrate to BIGINT or TIMESTAMP. Hosted MySQL providers' TIMESTAMP type is also 4 bytes by default, check the docs.
• Parsing ISO 8601 with regex. Half-implementations silently drop the timezone. Use the platform parser: new Date(s) in JavaScript, datetime.fromisoformat(s) in Python ≥ 3.11, Instant.parse(s) in Java.
• Excel auto-converts timestamps. Pasting 1747143012345 into Excel without prefixing it with ' (a literal apostrophe) makes Excel read it as a number, sometimes converting to scientific notation. Either format the column as Text first, or paste with the apostrophe prefix.

More frequently asked questions

Why was 1970-01-01 chosen as the epoch?

Convenience. Early Unix versions in the 1970s wanted an epoch they wouldn't overflow within a reasonable working lifetime. 1970-01-01 was a round date close to the development era, and a 32-bit second counter from there reaches comfortably to 2038. The choice is now etched into POSIX.1-2017 §4.16 and is one of the most stable cross-platform agreements in software. There is no inherent meaning to the date, no historical event, no astronomical anchor, just an arbitrary anchor that everyone agreed on.

What is the difference between UTC, GMT, and Zulu time?

For software purposes, they refer to the same wall-clock time. UTC (Coordinated Universal Time) is the modern standard, defined by atomic clocks and the BIPM. GMT (Greenwich Mean Time) is the older British astronomical standard that was the de facto world reference before atomic timekeeping. Zulu time is the NATO/military designator for UTC, written as the Z suffix in ISO 8601 (2026-05-13T14:30:00Z). UTC and GMT can differ by up to 0.9 seconds because UTC is steered to stay close to UT1 (mean solar time) via leap seconds, but no application that doesn't directly use UT1 will notice.

Why is 1970 sometimes shown when I expected something else?

Two common causes. First, the timestamp is in milliseconds but was passed to a function expecting seconds, or vice versa, giving you a date that's a factor of 1000 off. Second, the value is 0 or NaN, both of which most date libraries render as 1970-01-01T00:00:00Z. Inspect the raw integer width: 10 digits is seconds, 13 is milliseconds, 16 is microseconds, 19 is nanoseconds.

Will this tool handle negative timestamps for dates before 1970?

Yes. new Date(-86400000) returns 1969-12-31T00:00:00Z. JavaScript's Date can represent any moment from −271821-04-20 to +275760-09-13, which is roughly ±100 million days from the epoch. Beyond that range, the API returns Invalid Date. For historical dates, also be aware of the Julian-Gregorian transition (1582 in Catholic countries, 1752 in Britain, as late as 1923 in Greece) where calendar dates jumped by 10 to 13 days; date libraries vary in how they handle this.

Is my timestamp data sent anywhere?

No. All conversion runs in JavaScript inside your browser. The page never POSTs any value you enter. Open the Network tab in DevTools and convert a timestamp, you will see zero outbound requests during conversion. Safe for tokens with timestamp claims, internal log lines, or anything else you would not paste into a hosted service.