What time is this number? Timestamps in logs and IDs

A log line says 1700000000, a Windows file has 133444736000000000, a Chrome history row has 13344473600000000, and an ID such as a ULID or a Snowflake contains a time you can’t see. They are the same moment in different clothes. These tools decode them in your browser, so log lines and IDs from a real system aren’t sent anywhere.

1. Start with the length of the number

Paste it into Timestamp Converter. A plain Unix time counts from 1 January 1970, and the tool works out whether it is seconds, milliseconds, microseconds or nanoseconds from the number of digits, and says which it used. 1700000000 is 10 digits, so seconds: 2023-11-14T22:13:20.000Z.

Other systems use a different start point and unit, so they look wrong if read as Unix. A rough guide to the same moment:

If the number doesn’t convert to a believable date, choose a different format under Read as: the list covers Windows FILETIME or LDAP time, Apple Cocoa / Core Data time, Excel serial date, .NET ticks, Chrome / WebKit time, NTP time, GPS time, HFS+ time, FAT / DOS date and time, Julian Day and Modified Julian Day. The page also shows the same moment in all the others, so you can match what you see to a value you know. A date in the 1600s or 1970 is the clue that you chose the wrong one.

2. Find the time inside an ID

Some IDs hold the moment they were made. Paste a ULID or a MongoDB ObjectId and the tool recognises it by its shape and shows the time. For an X (Twitter) or Discord Snowflake, a Firebase push ID or a Bluesky TID, choose it under Read as. This answers “when was this record created?” from the ID alone.

The time is only part of the ID, so it can’t be turned back into one, and the time is when the ID was made, which may differ from when you think the record was.

3. Convert a whole log at once

For a column of timestamps, open Many timestamps at once, set Read as to the right format, and paste one a line. Lines that can’t be read say “Not read”, which often points to the one odd row in the set. Copy as CSV gives the results to paste into a spreadsheet.

To go the other way, type a date such as 2026-10-01T12:00:00Z in the main box to get the Unix seconds and milliseconds. A date and time with no zone is read as your local time, but a bare date such as 2026-10-01 is read as midnight UTC, so give the zone when it matters. Unix time in code at the bottom shows how to get and convert Unix time in a dozen languages.

4. Get the exact start and end of a day, week or month

A report for “last week” or “March” needs two exact timestamps. Under Start and end of a period, pick a Date, a Period (day, ISO week, month, quarter or year) and a Zone (UTC or Your local time) to get the first and last second to put in a query or a log filter. Weeks start on Monday. Choose the zone your system logs in: a day in UTC and a day in your local time are different spans.

Date Calculator answers the neighbouring questions: About one date gives the day of the year and its ISO week; Weeks of a year lists each week with its Monday and Sunday, for matching week numbers in a report to real dates; and Between two dates gives the exact span in years, months and days. It counts weekdays but not public holidays.

5. When the number is bytes in a file

A binary file or a network capture stores a timestamp as raw bytes, often the least significant byte first. In Hex Viewer, find the bytes: 00 f1 53 65 read from the right is 65 53 f1 00, which is hexadecimal 6553f100. Type that into Number Bases to get decimal 1700000000, then convert it as in step 1. Analyse the whole file lists readable text in the file with its offsets, which often finds a date string without any decoding.

If it doesn’t convert well, check the byte order and the width: the same eight bytes read the other way round give a date far from any you’d expect. FAT / DOS times in Read as accept hex (such as 0x58216000) directly.

6. Read the time zone and leap seconds with care

Unix time and most of the other numeric formats carry no time zone. They are one moment worldwide (FAT / DOS times are the exception, being local), and the tool shows it in UTC and in your local time. If a local time in a log looks an hour out, it is usually daylight saving time on the machine that wrote it. GPS time is converted with 18 leap seconds, which is right since 2017; NTP time wraps in 2036 and is read here as the first era. Treat a result as a strong hint for a matter that matters, and confirm against a second source.