/en/tool/timestamp-converter/ works Calculated in your browser
Paste anything that looks like a time into the field — a number, ISO string, date from an email, log line, or ObjectId from MongoDB — and the converter will identify how it interpreted the value and show the moment in all common formats at once, in any time zone. It also shows the difference between two moments, lets you shift a moment by an interval, provides calendar details, and parses an entire column of values with CSV export.
One field for everything: a number, date, or log string. The tool identifies what it is and shows where it went wrong if it misinterprets it.
The same number represents different dates in different systems. On the left is what you get when you read the input as belonging to another epoch; on the right is how the parsed moment is represented in that epoch.
| Epoch | If the input uses it | Moment in this scale | Copy |
|---|
The week number, day of the year, quarter, and the boundaries of the day, week, month, and year — all at once in the timestamp, so you don't have to assemble them manually with a query.
| Metric | Value | Unix, seconds | Copy |
|---|
Both fields understand the same formats as the main field: a number, an ISO string, or a date from an email. Calculations use the selected time zone's calendar, so daylight saving time is taken into account.
Start of the interval.
End of the interval. If it is earlier than A, the difference is calculated with its sign.
—
Moment plus or minus an interval
Empty means use the moment parsed above.
You can enter several chunks in a row: “+1 month −3 hours”, “+2w 4h”, “-45 minutes”.
—
Paste the entire export — you don't need to clean it down to one column. Each row is scanned for the first thing that looks like a time; everything else is kept as is to identify the row.
Empty
| Line | Found | Counted as | In the selected time zone | ISO 8601, UTC | Relative to now |
|---|
The value and explanation have already been filled in from the panel above. You can copy and paste the code without adding anything.
Enter a value in the single field. A number, ISO string, date from an email, ObjectId, or log string fragment—all are parsed, and the label next to it states how the tool interpreted the value. If that interpretation is wrong, correct it with the unit switch.
Select a time zone. The browser provides the full IANA list, while Russian time zones are shown as buttons on a separate line. The zone is applied immediately both to dates without an offset and to all output.
Use the button for the required row in the format table: ISO, RFC 2822, HTTP-date, SQL, a PostgreSQL expression, and a microsecond representation are shown side by side, so you do not need to copy an entire block for a single row.
The difference between two moments and shifting by an interval are in a separate section below. Both fields accept the same input as the main field, while “2 years 3 months 11 days” is calculated according to the selected time zone's calendar.
Paste a column of values or a log fragment into the batch field as is: there is no need to clean it up. The time is extracted from each line automatically, and the table can be exported to CSV.
The result link puts the value, unit, and time zone in the page address. You can send the link to someone else, and they will see exactly the same result.
timestamp = the number of seconds elapsed since January 1, 1970, in UTC
Unix time has no leap seconds: a day always contains exactly 86,400 seconds. As a result, it differs from astronomical time by several dozen seconds, which is precisely why it is convenient for calculating intervals. GPS time also has no leap seconds, but its count began in 1980 and has since moved 18 seconds ahead of UTC—those seconds must be subtracted separately.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
A day has 86,400 seconds.
1 000 000 000 ÷ 86 400 = 11,574 days and 6,400 seconds remaining.
Remainder: 6,400 seconds is 1 hour, 46 minutes, and 40 seconds.
11,574 days after January 1, 1970 is September 9, 2001.
In September 2001, Moscow used UTC+4—daylight saving time was still observed—so four hours are added to the value.
The result is September 9, 2001, at 01:46:40 UTC and 05:46:40 in Moscow. It was a Sunday, the 36th week of the year, and the 252nd day. In milliseconds, it is 1 000 000 000 000; in hexadecimal, 0x3B9ACA00.
By the number of digits. For current dates, ten digits means seconds, thirteen means milliseconds, sixteen means microseconds, and nineteen means nanoseconds. Get it wrong, and the date shifts by a factor of 1,000: seconds read as milliseconds produce a date in 1970, while milliseconds read as seconds produce the distant future. The tool states in the label how it interpreted your number, and you can override any guess with the switch.
A Z at the end means “this time is in UTC,” making the string unambiguous: its time zone is already known, so the switch has no effect. A string without Z or an offset is simply a clock reading, and only you know which clock it came from. That is why it has a “in selected zone / as UTC” switch: the same text in Moscow and London represents moments three hours apart.
Most likely Windows FILETIME: intervals of 100 nanoseconds since January 1, 1601. LDAP and Active Directory also return it in fields such as lastLogon. Seventeen digits usually indicate WebKit time—microseconds since the same 1601 epoch, used by Chrome and Safari. Eighteen digits beginning with 6 indicate .NET DateTime.Ticks, counted from year 1 AD. All three formats are detected automatically, and the “If this is not Unix time” table shows all interpretations at once so you can choose the right one at a glance.
The time zone is applied as a rule, not as a fixed offset: for each moment, the browser asks its IANA database what the clock showed then. That is why a 2001 date in Moscow gets UTC+4, while today’s date gets UTC+3. Calendar details show the date of the nearest clock change, and if the entered time falls in a skipped or repeated hour, the tool reports that on a separate line.
Yes, for systems that store time in a 32-bit signed integer: on January 19, 2038, the value will overflow and become negative. Modern systems use 64 bits, which will last for a period comparable to the age of the universe. But old firmware and databases with 32-bit fields are still around, so the warning for values above 2 147 483 647 remains.
This was done for simplicity: a day always has exactly 86,400 seconds, so the difference between two values is an exact number of seconds between them, without exceptions. The trade-off is a drift from astronomical time that accumulates over decades.
Excel includes February 29, 1900, even though that date did not exist in the calendar: the error was inherited from Lotus 1-2-3 for compatibility and kept forever. As a result, dates before March 1, 1900 are off by one day, while everything after that matches. Google Sheets uses the same numbering from December 30, 1899, so values transfer between them without recalculation.
Nothing from your data: parsing, batch processing, and CSV export all happen in the browser. There is one request, though—a HEAD request with an empty body to this same page. The response's Date header is used to compare it with your device clock. Neither the entered value nor the contents of the batch field are included in this request. If the request fails, the “Your clock vs. server clock” line simply shows a dash.
It will produce a negative number. The converter calculates and displays such values, but keep in mind that some libraries and databases reject negative timestamps, while others silently convert them to zero. Dates before 1900 have another complication: many time zones then used local solar time with offsets measured in an odd number of minutes, and the IANA database reproduces this accurately.
Creates passwords of the required length and assesses how difficult they are to crack.
Open