Конвертер даты в Unix timestamp
Tool guide
This converter turns an ordinary date and time into a Unix timestamp — the whole number of seconds elapsed since midnight on 1 January 1970. Choose the moment in the date-time field, press convert, and you get a value for an API parameter, a log filter or a token expiry field. The count comes from your device's own time zone, so the same input in London and Tokyo yields different seconds. See also: turn an epoch number back into a readable date, count the days between two dates, show a number in hexadecimal.
It is the number of seconds that have passed since midnight UTC on 1 January 1970, a moment known as the epoch. A single integer carries no formatting, language or time zone baggage, which makes it ideal for storing time in databases, passing it through APIs and comparing log entries — subtract two timestamps and you have a duration in seconds.
Whatever your operating system is set to. A datetime-local field holds wall-clock time with no zone attached, and the browser applies your offset from UTC when converting. If you need a strictly UTC value and you are, say, three hours ahead, subtract 10800 seconds from the number you get.
Seconds are the classic Unix unit, and most server-side APIs, cron fields and database columns expect exactly that. Milliseconds are a JavaScript convention, also used by some logging stacks. If the system you are feeding wants milliseconds, append three zeros to the copied value or multiply it by a thousand.
Yes — earlier dates count backwards and produce a negative number. 1 January 1960, for example, comes out at roughly minus 315 million seconds. Be aware that not every database engine or language handles negative epoch values gracefully, so test what happens at the receiving end before you rely on it.
On 19 January 2038 the timestamp passes 2,147,483,647, the limit of a signed 32-bit integer. Systems still storing time in that type wrap around and land in 1901. The converter itself handles such dates correctly because it uses a wider numeric type, but the system you are sending the value to may not.
Yes. The browser performs the conversion using the operating system's time zone database, so historical clock changes and shifting offsets are already known to it. Pick a date that falls inside a summer-time period in a zone that observes one and the extra hour is applied for you, with no manual correction.
No. The conversion is a handful of lines of code running in the open tab. Neither the moment you pick nor the number it produces is transmitted or written to any log, so it is safe to run internal release dates and timings taken from private tickets through it.
Before: 1 Jan 2021, 00:00 UTC
After: 1609459200 — goes straight into a from=... parameter
Before: 15 Aug 2026, 09:30 UTC
After: 1786786200 — the value for a start_time field
Before: 31 Dec 2026, 23:59 UTC
After: 1798761540 — this is what goes in a JWT exp claim
Your rating and feedback help decide what to improve next.
