Unix Timestamp Converter: Epoch to Date and Back

How to use the Unix Timestamp Converter: Epoch to Date and Back

1. Enter a valueType or paste a timestamp, a UUID or another ID, or a date such as 2024-03-01 10:30:00. You can also pick a date and time with the date picker, or click the current time at the top to use it.
2. Choose the time zoneThe time zone starts as the one your device uses. Change it to read a date in another zone, or to see the result written in another zone. Names such as Europe/Paris or America/New_York work, as does UTC.
3. Pick the right reading of a numberA number is shown under every format it could belong to, with the date each gives. The most likely one is selected. If the date looks wrong, choose another reading from the list.
4. Read the detailsThe details list the moment in UTC and in your zone, the weekday and week number, the time from now, and the same moment as Unix seconds, milliseconds, microseconds and nanoseconds, FILETIME, Chrome, .NET, Apple, and Excel values. Copy any of them.
5. Convert a whole logOn the second tab, paste a log or any text that contains timestamps. Each one that looks like Unix seconds, milliseconds, microseconds, or nanoseconds is converted, and you can add the date after it or replace it.

What a Unix timestamp is

The POSIX standard defines the number of seconds since the Epoch from a calendar date with a formula, and says that each and every day is counted as exactly 86,400 seconds. The Epoch is 1 January 1970 at 00:00:00 UTC. Because every day counts as the same length, Unix time ignores leap seconds. When a leap second is added, a Unix timestamp repeats or skips a value instead of counting it.

A Unix timestamp does not have a time zone. It names one moment, the same for everyone, and a time zone only matters when the moment is written as a date on a clock. That is why timestamps are a good way to store times, and why a date without a zone is not.

• 10 digits, such as 1700000000: seconds. This is the classic Unix time, and it covers 2001 to 2286.
• 13 digits, such as 1700000000000: milliseconds, as used by JavaScript's Date.now() and by Java.
• 16 digits: microseconds, used by many databases and by Python.
• 19 digits: nanoseconds, used by Go, by monitoring systems, and by high-resolution clocks.
• Fractions of a second are written after a decimal point, such as 1700000000.123.

Why one number can mean several dates

The number 1700000000 is 14 November 2023 as Unix seconds. As Apple Cocoa time it is a date in 2054, and as Mac HFS+ time it is a date in 1958. Nothing in the number tells them apart, so a converter has to guess or show all of them. This page shows all of them, and marks each as likely, possible, or unlikely.

The ranking is a rule of thumb. A reading is likely if the date falls within 15 years before and 5 years after today, possible if it falls between 1990 and 2040 or between 1980 and 2100, and unlikely otherwise. Among equally likely readings, the more common format comes first. It is a guide, not a proof. A file system timestamp from 1995 is a perfectly good date, so if the first answer is wrong, the list shows the others.

The other epochs

Each system picked its own starting point and unit, and these are the ones the page reads.

• Windows FILETIME: intervals of 100 nanoseconds since 1 January 1601 UTC, according to Microsoft. NTFS file times and Active Directory attributes use it.
• Chrome and WebKit time: microseconds since 1 January 1601 UTC. Chrome and Edge keep history, cookies, and downloads this way.
• .NET ticks: intervals of 100 nanoseconds since midnight on 1 January 0001, without leap seconds, as the DateTime.Ticks documentation says.
• Apple Cocoa time: seconds since 1 January 2001 UTC, the reference date of NSDate.
• Mac HFS+ time: seconds since 1 January 1904.
• Excel serial dates: days since 30 December 1899, with the time of day as a fraction, in the 1900 system, and days since 1 January 1904 in the 1904 system.
• Twitter and Discord snowflake IDs: the ID shifted right by 22 bits gives milliseconds since 4 November 2010 and 1 January 2015.

Excel dates and the day that never existed

Excel's 1900 date system counts a 29 February 1900 that did not exist. Microsoft explains that Lotus 1-2-3 made the mistake and that Excel kept it for compatibility. The result is that serial numbers below 61 are one day off from a true calendar. Serial 60 is the missing day, and Microsoft notes that the WEEKDAY function is wrong for dates before 1 March 1900. This page follows Excel, so serial 61 is 1 March 1900 and serial 60 is reported as not a real date.

Older Excel workbooks from the Mac use the 1904 system, which starts on 1 January 1904 and has no such gap. The same date is 1,462 days lower in that system, which is a common cause of dates that are four years off after a file is moved between machines.

IDs that contain a time

Many IDs begin with a timestamp so that they sort by creation time. A UUID version 7 starts with 48 bits of Unix milliseconds, and versions 1 and 6 carry a 60-bit count of 100-nanosecond intervals since 15 October 1582, as RFC 9562 defines. A MongoDB ObjectId starts with 4 bytes of Unix seconds. Twitter and Discord snowflakes hold the milliseconds since their own start dates in the upper bits.

Paste any of them and the page shows when the ID was created. A version 4 UUID is random and has no time. The time in a version 1 UUID is whatever the clock of the machine that made it said, so it is only as right as that clock.

Time zones and daylight saving time

To turn a date and a time of day into a timestamp you need the time zone, because the same wall-clock time is a different moment in each zone. Twice a year, in zones that use daylight saving time, the wall clock also misbehaves. When the clocks jump forward, an hour does not exist, so a time such as 02:30 on that night has no moment. When the clocks go back, an hour happens twice, so 01:30 on that night is two different moments.

This page does not pick one silently. For a time that does not exist it shows the two ways to read it, using the offset from before the change and the one from after it, and for a time that happens twice it shows both moments, the first and the second. The results were checked against Python's zoneinfo module for 13 time zones around their daylight saving changes. Time zone rules come from your browser, which uses the IANA time zone database.

The year 2038 problem

A signed 32-bit integer holds Unix seconds up to 2,147,483,647, which is 19 January 2038 at 03:14:07 UTC. One second later it overflows to a date in 1901. Systems that still keep time in 32 bits, such as old embedded devices, file formats, and databases, will break then unless they are changed. An unsigned 32-bit integer lasts until 7 February 2106. The details of every result say whether the moment fits in 32 bits.

Converting timestamps in a log

Logs are full of raw timestamps. The log tab finds numbers of 10, 13, 16, or 19 digits that fall between 1990 and 2100 when read as Unix time, and writes the date after each one, or in its place. Other numbers, such as process IDs, order numbers, and version numbers, are left alone, but a long ID that happens to look like a timestamp can be converted by mistake, so glance at the result before you rely on it.

Limits and accuracy

• The ranking of readings is a rule of thumb about which dates are sensible. It cannot know what a number means in your data.
• Unix time and the other counts here ignore leap seconds, so the page does not model them. Times are shown as UTC and local clock times, without a 23:59:60.
• Dates before 1582 use the proleptic Gregorian calendar, and the range is limited to what the browser can hold, about 275,000 years either side of 1970.
• Time zone rules and abbreviations come from your browser. An old browser may lack a recent rule change, and an abbreviation can show as an offset such as GMT+1 where there is no common one.
• The epochs of Chrome, Apple, Twitter, and Discord come from public documentation and from how those systems are known to work, and a vendor can change its format.
• A timestamp in the log tab is read as Unix time only. Other formats in a log, such as FILETIME, are not found automatically.
• Text of up to 5 million characters can be converted in the log tab.

Frequently asked questions