What is this timestamp? How to decode a number when you do not know the format

Paste the number into EPOCH. It tries seventeen formats, reads hex both ways round, and ranks the answers by which ones land on a date that could plausibly be real rather than in 1601 or the year 12000. You get every candidate with its epoch and its tick size, so you can judge the reading rather than take it. Nothing is uploaded, and it works with the network off.

Why there are seventeen of them

A timestamp is a count of ticks since a moment somebody chose. There is no standard for either. Every platform picked its own starting point, usually for a reason that made sense at the time and none at all now, and picked its own tick because the hardware suited it.

So the same instant is a ten-digit number on a Unix machine, an eighteen-digit number in a Windows file record, and a five-figure decimal in a spreadsheet. None of them is wrong. Read one as another and you are out by anywhere from a few years to four centuries.

The whole table, anchored to one instant

Every row below is midday UTC on 20 September 2026, so the shapes can be compared directly. The digit count is usually enough to narrow it to two or three candidates.

The strange epochs, and why

• 1601 for Windows, because the Gregorian calendar repeats on a four-hundred-year cycle and 1601 is the start of the first whole cycle before the machine was built. It makes the leap-year arithmetic clean.
• 1899-12-30 for spreadsheets, not the 31st. Lotus 1-2-3 treated 1900 as a leap year, which it is not, and Excel copied the error deliberately so the two agreed. The epoch was shifted back a day to make the rest of the dates come out right. It is a bug preserved as a standard for forty years.
• 1582-10-15 for UUID version 1, the day the Gregorian calendar came into use.
• 1904 for classic Mac, so that a 32-bit unsigned count of seconds would not need to handle dates before 1904 — and, usefully, so that every year in range is after the last non-leap century year.
• 2001 for Cocoa, simply because that is when Mac OS X shipped.

How to narrow it down yourself

Before reaching for a tool, three things get you most of the way:

• Count the digits. Ten is almost always Unix seconds. Thirteen is Unix milliseconds. Sixteen is microseconds, nineteen is nanoseconds. Seventeen and eighteen mean you are in Windows or .NET territory.
• Look at where it came from. A number out of a browser history database is Chrome's microseconds-since-1601. One out of a Windows event log or an NTFS record is FILETIME. One out of a spreadsheet cell is days. One out of an iPhone backup is seconds since 2001.
• Sanity-check the answer. If a reading gives 1601, 1904 or the year 55000, it is the wrong reading. This is the check that actually resolves it, and it is why every candidate is shown with its date rather than one being picked for you.

Hex, and the trap of reading it one way

Timestamps arrive in hexadecimal as often as in decimal — out of a registry dump, a packet capture, a database blob. A hex timestamp has an extra ambiguity on top of the format: the byte order. The same eight bytes read big-endian and little-endian are two completely different numbers, and which one is right depends on the machine the file came from, not the file.

Both readings are tried and both are shown where both give a plausible date. Anything that silently picks one is right on Intel and wrong on everything else, or the reverse.

The part that is usually skipped: what the number does not tell you

A timestamp is an instant, not a time. It carries no time zone and no offset, because there is nothing to carry — almost every format above counts from a fixed moment in UTC. The local time it corresponds to depends on where the event happened and what the rules were on that date, which is not the same as what they are now.

This bites in evidence more than anywhere else. A file created at 23:30 UTC on 30 March has one date in London and another in Los Angeles. A timestamp from before a country changed its daylight-saving rules converts differently from one after. If the local time matters, the zone has to come from somewhere other than the number, and that is a fact about the case, not about the arithmetic.

Two of the formats in the table are honest exceptions worth knowing about: packed MS-DOS and FAT times are stored in local time with no zone recorded at all, which is why file dates on a USB stick shift when it crosses a border; and GPS time does not observe leap seconds, so it has drifted steadily away from UTC since 1980.

The short version

Why it matters that it stays on your machine

The timestamps people need decoded come out of things they should not be pasting into a website: an event log from a compromised machine, a browser history in a disclosure bundle, the metadata of a file in a dispute, a database record under legal hold. The number itself looks harmless, which is exactly why it gets pasted.

It is arithmetic. It needs no server, and a page that does it in the tab can be checked by turning the network off and watching it carry on working.