Quick answer
A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970. For example, 1700000000 is 22:13:20 UTC on 14 November 2023. A 13-digit number is usually milliseconds (JavaScript, Java) and a 10-digit number is seconds (PHP, Python, databases).
What is a Unix timestamp?
Convert Unix timestamps to dates in Vietnam time, UTC and your own time zone, plus ISO 8601, RFC 2822 and a relative “how long ago”. The unit (seconds, milliseconds, microseconds or nanoseconds) is detected from the number of digits, you can override it, and sub-millisecond digits are kept. In the other direction, pick a date and time, choose which time zone it's in and copy the timestamp. A live Unix clock runs at the top of the page.
How to convert a timestamp
- 1
Paste a timestamp into “Unix timestamp” or click “Use the current time”; the tool tells you whether it read seconds or milliseconds.
- 2
If the unit is wrong (say a millisecond value from 1970), pick the right one under “Unit”.
- 3
Read the result in Vietnam time, UTC, your time zone, ISO 8601 and RFC 2822, and copy the line you need.
- 4
For the reverse, pick a date and time under “Date → timestamp”, choose the time zone it refers to, then copy the seconds or milliseconds.
Detecting the unit from the digit count
| Digits | Unit | Common in | Example (same instant) |
|---|---|---|---|
| 10 | Seconds | PHP time(), Python time.time(), MySQL UNIX_TIMESTAMP(), JWT exp | 1700000000 |
| 13 | Milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() | 1700000000000 |
| 16 | Microseconds | PostgreSQL, Python time.time_ns() // 1000 | 1700000000000000 |
| 19 | Nanoseconds | Go time.UnixNano(), Prometheus | 1700000000000000000 |
Swipe sideways to see the whole table →
The rule used here: up to 11 digits is seconds (good until the year 5138), 12–14 milliseconds, 15–17 microseconds, anything longer nanoseconds.
Notable timestamps
| Timestamp (seconds) | Moment (UTC) | Why it matters |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The starting point (Unix epoch) |
| 1000000000 | 2001-09-09 01:46:40 | One billion seconds |
| 1700000000 | 2023-11-14 22:13:20 | 1.7 billion seconds |
| 2000000000 | 2033-05-18 03:33:20 | Two billion seconds |
| 2147483647 | 2038-01-19 03:14:07 | Largest signed 32-bit integer: the “Year 2038 problem” |
| -86400 | 1969-12-31 00:00:00 | Negative values are before 1970 |
Real-world examples
Reading a JWT expiry
The exp claim is a timestamp in seconds, such as 1767225600. Paste it in: 1 January 2026 00:00:00 UTC.
Server logs in milliseconds
A log line has created_at = 1730000000000 (13 digits). The tool reads it as milliseconds: 27 October 2024 03:33:20 UTC.
Scheduling a launch in local time
Need the timestamp for 8 pm on 11 November 2026 in Vietnam? Pick that date and time, keep “Vietnam time” and you get 1794402000 seconds. Choosing UTC by mistake would put it seven hours off.
Comparing two moments
Subtract two timestamps in seconds and divide by 86,400 to get days: 1767225600 − 1735689600 = 31,536,000 seconds, exactly 365 days.
Common problems and fixes
- The date comes out as 1970.
- A seconds value is being read as milliseconds (or the other way round). Check the digit count and pick the right unit.
- It's off by exactly a few hours.
- Timestamps are always UTC; the difference is your time zone offset. When converting a date to a timestamp, choose the time zone you actually mean.
- The year is something like 50000.
- A millisecond timestamp is being read as seconds. Leave it on auto-detect or choose milliseconds.
- Microseconds are lost.
- JavaScript dates are only precise to the millisecond. The tool still shows the remaining digits so no data is lost.
- A 32-bit system fails on dates after 2038.
- A signed 32-bit integer only holds up to 2147483647. Store timestamps as 64-bit numbers (BIGINT, int64).
How Unix time works
Unix time counts seconds since the epoch, 1970-01-01 00:00:00 UTC, and doesn't depend on time zones: a given instant has the same number in London and in Tokyo. Time zones only come in when you turn that number into a readable date. That's why databases and APIs should store timestamps or UTC, converting to local time only for display.
Unix time ignores leap seconds: every day counts as exactly 86,400 seconds.
ISO 8601 and RFC 2822
ISO 8601 (2026-10-21T13:00:00+07:00) is the format to use in JSON and APIs: easy to parse and it sorts alphabetically. RFC 2822 (Wed, 21 Oct 2026 06:00:00 +0000) is used in email and some HTTP headers. Both include the time zone offset.
Glossary
- Epoch
- 1970-01-01 00:00:00 UTC, the zero point of Unix time.
- UTC
- Coordinated Universal Time, the reference time zone with no daylight saving.
- UTC offset
- How far a time zone is ahead of or behind UTC, such as +07:00 for Vietnam.
- ISO 8601
- The year-month-dayThour:minute:second date format with a time zone offset.
- Year 2038 problem
- Second-based timestamps overflow signed 32-bit integers at 03:14:07 UTC on 19 January 2038.
- Leap second
- An extra second added to UTC to match the Earth's rotation; Unix time doesn't count it.
Frequently asked questions
What's the current Unix timestamp?
See the clock at the top of the page: seconds and milliseconds update every second from your device's clock.
How do I tell seconds from milliseconds?
Count the digits: a present-day timestamp has 10 digits in seconds and 13 in milliseconds. The tool detects it and says which.
Does a timestamp depend on the time zone?
No. The same instant has the same timestamp everywhere; only the displayed date and time differ.
What does a negative timestamp mean?
A moment before 1 January 1970. For example, −86400 is 31 December 1969 00:00:00 UTC.
Does this account for daylight saving time?
Yes for your own time zone, using your browser's time zone data. Vietnam stays on UTC+7 all year.
Is any data sent anywhere?
No. Every conversion runs in your browser using your device's clock.
Ratings and comments
Loading…