Timestamp Converter
Convert between Unix timestamps and datetime formats
Timestamp to Date
Date to Timestamp
Global Timezone Comparison
Common Format Examples
What is a Timestamp?
A timestamp is a numeric value representing a specific time. Unix timestamp is the number of seconds elapsed since January 1, 1970 00:00:00 UTC (called Unix Epoch). It is the standard way to represent time in computer systems, with cross-platform and cross-timezone consistency. Timestamps are divided into seconds-level (10 digits) and milliseconds-level (13 digits). Seconds-level timestamps are commonly used in Unix/Linux systems, while milliseconds-level are common in JavaScript and other programming languages. With timestamps, the first question is whether the value is in seconds, milliseconds, or a formatted local time. Unix timestamps represent timezone-independent instants, but displaying them as dates depends on timezone and daylight-saving rules. The tool helps debug logs, APIs, databases, cache expiry, and scheduled events. For user-facing communication, the timezone should be shown clearly so the same instant is not mistaken for different local dates.
How to Use
Timestamp to Date
- Enter a Unix timestamp in the left card
- Select target timezone (e.g. Beijing Time UTC+8)
- Click convert button to see the converted datetime
- Results include: standard format, ISO 8601, Chinese format, and more
Date to Timestamp
- Select date and time in the right card
- Select the source timezone used by that date and time
- Click convert button to get the Unix timestamp
- Results include seconds and milliseconds timestamps
Timezone Tips
- Check whether the source value uses seconds or milliseconds; mixing 10-digit and 13-digit timestamps is a common cause of wrong dates.
- Always confirm the intended timezone when converting human-readable dates, especially for logs, scheduled jobs, and cross-region systems.
Use Cases
Technical Principle
A Unix timestamp counts elapsed time from the Unix Epoch, defined as 1970-01-01T00:00:00Z, which is the zero point that POSIX time uses to label every later instant. POSIX time deliberately ignores leap seconds: each calendar day is treated as exactly 86,400 seconds, so two timestamps that span a leap second insertion will be off by one second from a strict atomic clock count, but the trade-off is that converting between epoch seconds and UTC calendar fields stays a clean divmod by 86,400. The two formats that show up daily are seconds (10 digits today, e.g. 1717000000) and milliseconds (13 digits, e.g. 1717000000000). JavaScript's Date.now() returns milliseconds since the epoch and `new Date(ms)` expects milliseconds, while Unix `date +%s`, Go's time.Unix, and most database TIMESTAMP columns use seconds. Length-based detection is the usual disambiguation: a 10-digit value falls in the 2001-2286 range when read as seconds, and the same value read as milliseconds would be inside 1970. Displaying a timestamp requires a timezone. UTC is written with the suffix `Z`; other offsets use `±HH:MM` (e.g. `+08:00` for China Standard Time, `-05:00` for US Eastern Standard). ISO 8601 allows several optional separators while RFC 3339 is a stricter profile that fixes them, which is why API specs typically require RFC 3339 with an explicit offset. Legacy systems that store epoch seconds in a 32-bit signed integer overflow at the maximum positive value 2147483647, which decodes to 2038-01-19T03:14:07Z (the Y2038 problem); 64-bit storage pushes the boundary well past human relevance.
- Unix Epoch is fixed at 1970-01-01T00:00:00Z and POSIX time ignores leap seconds, so every day is treated as exactly 86,400 seconds.
- JavaScript Date.now() returns milliseconds; `Math.floor(Date.now() / 1000)` converts to seconds-level timestamp.
- Y2038 boundary: signed 32-bit timestamp overflows at 2147483647 = 2038-01-19T03:14:07Z; 64-bit storage avoids this.
- ISO 8601 vs RFC 3339: RFC 3339 is a stricter ISO 8601 profile that requires an explicit offset (`Z` or `±HH:MM`) and is preferred for APIs and logs.
- ECMAScript Date is limited to ±100,000,000 days from epoch (≈ ±273,785 years), which is why `new Date(8.64e15)` and `new Date(-8.64e15)` are the absolute bounds.
- JWT `exp`, `iat`, and `nbf` claims, `Cache-Control: max-age`, and Cookie `Expires` all use Unix seconds (RFC 7519, RFC 7234), so add/subtract them directly against `Math.floor(Date.now()/1000)`.
- Timezone affects the rendered datetime but not the timestamp value itself; the same epoch second renders as different wall-clock times in UTC+8 and UTC-5.
Examples
Convert a 10-digit Unix timestamp to a readable date
Input: 1781526600
UTC: 2026-06-15 12:30:00
Beijing (UTC+8): 2026-06-15 20:30:00
ISO 8601: 2026-06-15T12:30:00Z
POSIX: IEEE 1003.1 defines Unix time as seconds since 1970-01-01 00:00:00 UTC (the Epoch)
ISO: ISO 8601 defines the YYYY-MM-DDThh:mm:ssZ format for unambiguous datetime representationConvert a date back to a timestamp
Input: 2026-01-01 00:00:00 (UTC)
Seconds (10 digits): 1767225600
Milliseconds (13 digits): 1767225600000
Unix command: date -d @1767225600
Note: JavaScript Date.getTime() returns milliseconds; Python time.time() returns seconds (float)
POSIX: The time_t type is traditionally a 32-bit or 64-bit signed integerTell seconds and milliseconds apart
1781526600 -> 10 digits, seconds -> 2026-06-15 12:30:00 UTC
1781526600000 -> 13 digits, milliseconds -> 2026-06-15 12:30:00.000 UTC
Common bug: a 13-digit value read as seconds would be year ~74,000
Quick check: 10-11 digits = seconds (1970-2286), 13 digits = milliseconds (JavaScript default)Decode a JWT exp claim
JWT payload: { "exp": 1798617600 }
Decoded: 2027-01-01 00:00:00 UTC
Current now: 1781526600
Valid for: 17,091,000 seconds (~198 days remaining)
RFC: RFC 7519 section 2 defines NumericDate as seconds since the EpochY2038 boundary check
Max signed 32-bit timestamp: 2147483647
Decoded: 2038-01-19 03:14:07 UTC
One second later: 2147483648 -> overflow on legacy 32-bit systems
Fix: use 64-bit time_t (default on modern Linux/macOS) or store as ISO 8601 string
POSIX: 32-bit time_t systems will wrap around after 2038-01-19FAQ
What is a Unix timestamp?
The number of seconds elapsed since 1970-01-01 00:00:00 UTC, the 'Unix epoch'. JavaScript and many APIs use milliseconds since the same epoch (Unix timestamp × 1000). The page accepts both and shows the corresponding date in your local time and UTC.
Seconds vs milliseconds vs microseconds vs nanoseconds?
Different systems use different precision. Unix `time()` returns seconds. JavaScript Date.now() returns milliseconds. Java Instant supports nanoseconds. The page auto-detects by digit count: 10 digits = seconds (in 2001-2286), 13 = milliseconds, 16 = microseconds, 19 = nanoseconds.
Why is January 19, 2038 important?
It is the 'Year 2038 problem': 32-bit signed Unix timestamps overflow at 03:14:07 UTC on 2038-01-19. Systems still using a 32-bit time_t will roll back to 1901. Modern 64-bit systems are unaffected for billions of years; legacy embedded systems need a fix.
How does it handle time zones?
Unix timestamps are inherently UTC. The page shows your local time, UTC, and lets you pick any IANA time zone (Asia/Shanghai, America/New_York, Europe/London) for additional displays. Daylight saving is applied automatically per zone.
Why does parsing 'YYYY-MM-DD' assume UTC in some places?
ISO 8601 dates without a time zone are ambiguous. JavaScript's Date constructor treats date-only strings as UTC and date-time strings as local - a notorious source of off-by-one-day bugs. The page is explicit about which time zone applies.
Is the conversion done locally?
Yes. The math is JavaScript Date plus Intl.DateTimeFormat. No timestamps are uploaded.
Can I generate a future timestamp?
Yes. Pick a future date and the page returns the corresponding timestamp. Useful for setting JWT exp claims, cron job test dates, or cache expiry windows in code.