Epoch / Unix Timestamp Converter

Unix time (also POSIX time or epoch time) is the number of seconds elapsed since 1970-01-01 00:00:00 UTC, the Unix epoch. It has no time zone: two machines in Hyderabad and Toronto reading the clock at the same instant get the same number. Times before 1970 are negative. Leap seconds are deliberately ignored, so every day is exactly 86,400 seconds in this scale, which keeps arithmetic simple at the cost of a one-second wobble whenever the astronomers insert one. Because it is a plain integer, it sorts, subtracts and indexes well, which is why databases, log files, file systems and tokens all use it.

What this converter does

The clock at the top shows the current Unix time in seconds and ticks every second. The "Timestamp to Date" box takes a number and shows it two ways: your browser's local time (via toLocaleString(), so in India that is IST) and UTC. It decides the unit by size: a value above 99,999,999,999 (twelve or more digits) is treated as milliseconds, anything smaller as seconds. The "Date to Timestamp" box parses a date string with the browser's Date parser and returns whole seconds. Microsecond and nanosecond values are not detected; divide by 1,000 or 1,000,000 first. JavaScript numbers are exact only up to 2^53 - 1, so a 19-digit nanosecond value could not be represented precisely anyway.

Which unit is my timestamp?

Two other counters are easily mistaken for Unix time. Windows FILETIME counts 100-nanosecond intervals since 1601-01-01 and .NET ticks count the same interval since 0001-01-01; both are 18 or 19 digits and need a different epoch. Excel stores dates as days since 1899-12-30 with the time as a fraction, so 45292 is 1 January 2024.

The time zone trap in date strings

Converting a date back to a timestamp depends on how the string is parsed. By the JavaScript specification, a date-only string such as 2024-01-01 is read as midnight UTC, but a date-time string without an offset, such as 2024-01-01T09:00:00, is read as local time. Other formats fall back to engine-specific rules. The reliable habit is to always write the offset: 2024-01-01T00:00:00Z is 1704067200 while 2024-01-01T00:00:00+05:30 is 1704047400; the 19,800-second gap is exactly the 5 hours 30 minutes of Indian Standard Time. IST has no daylight saving, and its IANA name is Asia/Kolkata. Store and transmit UTC or a full RFC 3339 string with an offset, and convert to local time only when displaying to a person.

Limits: 2038 and beyond

A signed 32-bit integer runs out at 2,147,483,647, which is 2038-01-19 03:14:07 UTC. After that second it wraps to a negative number and reads as December 1901. Modern operating systems and languages use 64-bit values, but the limit survives in places: MySQL's TIMESTAMP column type ends at 2038-01-19 (use DATETIME for later dates), old embedded firmware, and some file formats. JavaScript's Date covers plus or minus 8.64 x 10^15 milliseconds, about 285,000 years either side of 1970, so the browser is not the bottleneck.

Leap seconds

UTC has had 27 leap seconds since 1972, the last on 31 December 2016. Unix time does not count them: during a leap second the clock either repeats a value or, on systems using Google's or Amazon's "smear", runs slightly slow for a few hours around midnight. For nearly every application this is invisible, but it explains why a difference between two timestamps can be off by one second across those dates. The international decision in 2022 was to stop inserting leap seconds by 2035.

Command-line and SQL equivalents

date +%s                                        # now, in seconds
date -d @1704067200                             # GNU/Linux: timestamp to local time
date -u -r 1704067200                           # macOS / BSD
[DateTimeOffset]::FromUnixTimeSeconds(1704067200)          # PowerShell
python3 -c "import datetime as d; print(d.datetime.fromtimestamp(1704067200, d.timezone.utc))"
node -e "console.log(new Date(1704067200*1000).toISOString())"
SELECT to_timestamp(1704067200), EXTRACT(EPOCH FROM now());   -- PostgreSQL
SELECT FROM_UNIXTIME(1704067200), UNIX_TIMESTAMP();          -- MySQL
SELECT datetime(1704067200, 'unixepoch');                    -- SQLite

1. Read the live Unix time at the top of the page; press Refresh to reset the counter if the tab was in the background.
2. Paste a 10-digit (seconds) or 13-digit (milliseconds) timestamp into Timestamp to Date and press Convert to see it in your local time zone and in UTC.
3. For a microsecond or nanosecond value, divide by 1,000 or 1,000,000 first so it is in milliseconds or seconds.
4. Type a date into Date to Timestamp, ideally with an explicit offset such as 2024-01-01T09:30:00+05:30, and press Convert to get Unix seconds.
5. Multiply the result by 1000 if the destination (JavaScript, Java, Kafka) expects milliseconds.

• Reading timestamps in raw application logs, audit trails and S3 or CloudWatch exports.
• Building a time-bounded query against a table that stores Unix integers instead of a date type.
• Checking why a JWT or a cache entry expires immediately (seconds versus milliseconds confusion).
• Cross-referencing an incident across services that log in different units and zones.
• Confirming the 2038 exposure of a MySQL TIMESTAMP column or a legacy 32-bit device.
• Converting an IST meeting time to UTC for a cron schedule on a server that runs in UTC.