() seconds (microseconds) elapsed since January 1, 1970 00:00:00 GMT +00:00.
Unix time (POSIX time, Unix timestamp) is the number of seconds that have passed since 1 January 1970 00:00:00 UTC. That moment is called the Unix Epoch. For example, 1700000000 is 14 November 2023 22:13:20 UTC.
Why it is convenient
One number instead of a date. Time is an integer, so it is easy to compare, sort and subtract: the difference of two timestamps is an interval in seconds.
Compact. 4 or 8 bytes instead of a string with a date, a time and a zone.
Independent of time zones. At any given moment the timestamp is the same on a server in Moscow and in New York. Only the conversion to a human-readable date differs, and that is done with the zone when displaying.
Seconds, milliseconds, microseconds
Classic Unix time is in seconds, but many systems use smaller units. The easiest way to tell the unit is the number of digits (for current dates):
Digits
Unit
Used by
Example
10
seconds
Unix, PHP, MySQL, Python int(time.time())
1700000000
13
milliseconds
JavaScript Date.now(), Java
1700000000000
16
microseconds
PostgreSQL, Go UnixMicro()
1700000000000000
19
nanoseconds
Go UnixNano(), logs
1700000000000000000
A common mistake is passing milliseconds where seconds are expected: you get a date somewhere around the year 55 000.
Time zones
A timestamp does not contain a time zone — it always counts from UTC. The zone is needed only to convert to a date and back. So:
store time in the database as a timestamp or in UTC, and convert it to the user's zone when displaying;
when converting back (date → timestamp), always specify the zone: "2026-10-06 12:00" in Moscow and in London are different moments, 2–3 hours apart;
daylight saving time only affects the conversion to a date; the timestamp itself runs uniformly.
Leap seconds
Unix time assumes every day has exactly 86,400 seconds and ignores UTC leap seconds: when one is inserted, the second number simply repeats. This is invisible in everyday tasks; precise scientific work uses the TAI scale.
The year 2038 problem
If a timestamp is stored in a signed 32-bit integer, its maximum is 2147483647, i.e. 19 January 2038 03:14:07 UTC. One second later the value overflows and becomes negative, and the system thinks it is 13 December 1901. The fix is 64-bit values, enough for about 292 billion years. Modern operating systems and languages already use 64 bits, but the problem remains for old databases (MySQL's TIMESTAMP type), embedded devices and binary file formats.
How to get the current timestamp
Where
Command
Linux / macOS
date +%s
JavaScript
Math.floor(Date.now() / 1000)
PHP
time()
Python
int(time.time())
Go
time.Now().Unix()
Java
Instant.now().getEpochSecond()
C#
DateTimeOffset.UtcNow.ToUnixTimeSeconds()
MySQL
SELECT UNIX_TIMESTAMP();
PostgreSQL
SELECT extract(epoch FROM now());
SQLite
SELECT strftime('%s', 'now');
Notable moments
Timestamp
Date (UTC)
Why notable
0
1970-01-01 00:00:00
start of the Unix Epoch
1000000000
2001-09-09 01:46:40
the first billion seconds
1234567890
2009-02-13 23:31:30
a "pretty" number celebrated by programmers worldwide
2000000000
2033-05-18 03:33:20
two billion seconds
2147483647
2038-01-19 03:14:07
the limit of a 32-bit timestamp
How to use the calculator
Choose a time zone — all conversions use it, and the choice is remembered.
From date — fill in day, month, year and time and press "Execute" to get the timestamp.
Date as a string accepts the strtotime format: now, tomorrow, +1 week 2 days, 2026-10-06 12:00.
From Time Stamp — enter a number in seconds to see the date.