A Unix timestamp (also called epoch time or POSIX time) counts the seconds that have passed since 00:00:00 UTC on 1 January 1970. Computers, databases, logs and APIs use it because it is one plain number with no time-zone ambiguity. This Timestamp Converter turns a timestamp into a readable date in your local time, UTC and ISO 8601 format, and turns any date and time back into a Unix timestamp in seconds and milliseconds.
How to use the timestamp converter
- Timestamp → Date: paste a Unix timestamp and press Convert. Both 10-digit (seconds) and 13-digit (milliseconds) values are detected automatically.
- Date → Timestamp: switch tabs, pick a date and time (in your local time zone) and press Convert to get the timestamp in seconds and milliseconds.
How the conversion works
Timestamp (s) = floor(milliseconds since epoch ÷ 1000)
Unix time ignores leap seconds: every day is treated as exactly 86,400 seconds. The timestamp is the same everywhere on Earth at a given moment. Only its display changes with the time zone. In India (IST, UTC+5:30), the timestamp 0 is 1 January 1970, 05:30 AM.
Seconds vs milliseconds
| Digits (today) | Unit | Used by |
|---|---|---|
| 10 | Seconds | Unix/Linux, PHP time(), Python time.time() (as float), MySQL UNIX_TIMESTAMP(), JWT exp/iat |
| 13 | Milliseconds | JavaScript Date.now(), Java System.currentTimeMillis(), many REST APIs |
| 16 | Microseconds | PostgreSQL internals, some logging systems |
| 19 | Nanoseconds | Go time.UnixNano(), high-resolution tracing |
A very common bug is treating milliseconds as seconds, which gives a date tens of thousands of years in the future, or the reverse, which gives a date in January 1970.
Notable timestamps
| Timestamp | Date (UTC) | Why it matters |
|---|---|---|
| 0 | 1 Jan 1970 00:00:00 | The Unix epoch |
| 1,000,000,000 | 9 Sep 2001 01:46:40 | “Billennium” |
| 1,700,000,000 | 14 Nov 2023 22:13:20 | Recent round number |
| 2,000,000,000 | 18 May 2033 03:33:20 | Next billion mark |
| 2,147,483,647 | 19 Jan 2038 03:14:07 | Maximum signed 32-bit value: the Year 2038 problem |
The Year 2038 problem
Systems that store Unix time in a signed 32-bit integer will overflow after 03:14:07 UTC on 19 January 2038 and wrap around to December 1901. Modern 64-bit operating systems, languages and databases use 64-bit time and are safe for billions of years. Embedded devices, old file formats and legacy database columns such as MySQL’s TIMESTAMP type, which tops out at 2038, still need attention.
Getting the current timestamp in code
Python: import time; int(time.time())
PHP: time()
Java: Instant.now().getEpochSecond()
Bash: date +%s
MySQL: SELECT UNIX_TIMESTAMP();
PostgreSQL: SELECT EXTRACT(EPOCH FROM now());
ISO 8601: the human-friendly standard
When people need to read the time too, use ISO 8601: 2026-11-02T16:45:00Z (the Z means UTC) or 2026-11-02T22:15:00+05:30 (IST). Always include the offset. A timestamp without a zone is the most common cause of “off by 5½ hours” bugs in Indian apps. To compare local times in different cities, use the Time Zone Converter.
Frequently asked questions
What is a Unix timestamp?
The number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It is the same everywhere in the world at any given moment.
How do I know if a timestamp is in seconds or milliseconds?
For current dates, a 10-digit number is seconds and a 13-digit number is milliseconds. The converter detects this automatically.
How do I convert a Unix timestamp to IST?
Add 5 hours 30 minutes to the UTC time, or let the converter display it in your device’s local time. If your device is set to India, that is IST.
What is the Year 2038 problem?
Signed 32-bit Unix time overflows at 03:14:07 UTC on 19 January 2038. Systems still using 32-bit time fields may fail or show 1901 dates. 64-bit systems are not affected.
Does Unix time include leap seconds?
No. Unix time assumes every day has exactly 86,400 seconds, so leap seconds are not counted.