Unix Timestamp Converter
Parse, convert, and calculate Unix epoch timestamps across second (10-digit), millisecond (13-digit), microsecond (16-digit), and nanosecond (19-digit) resolutions. Generates synchronized UTC, ISO 8601, RFC 2822, and device-local outputs.
| Resolution | Value | Action |
|---|---|---|
| Seconds (s) | 1791389502 | |
| Milliseconds (ms) | 1791389502000 | |
| Microseconds (μs) | 1791389502000000 | |
| Nanoseconds (ns) | 1791389502000000000 | |
| Hexadecimal Unix Seconds | 0x6AC66F3E |
How to Use the Converter
- Timestamp to Date: Input any epoch integer. The converter parses unit resolution automatically and outputs UTC, local browser time, ISO 8601, and relative offsets.
- Date to Timestamp: Under the Date → Timestamp tab, select calendar date, clock time, and timezone mode (Local, UTC, or custom offset) to compute epoch seconds and milliseconds.
- Epoch Math & TTL: Use the Epoch Math & TTL tab to add or subtract temporal offsets (seconds to years) from any timestamp base for API token expiry (
exp) or cache invalidation planning. - Batch Processing: Under the Batch Converter tab, paste raw server logs or lists of timestamps to generate and export parsed multi-format CSV files.
Timestamp Precision: The 10, 13, 16, and 19-Digit Standard
Runtime environments use different standard precision levels. Identifying digit length prevents the common 1,000x scaling error when exchanging timestamps across systems.
| Resolution | Digits | Example | Valid Horizon | Standard Runtime Ecosystem |
|---|---|---|---|---|
| Seconds (s) | 10 digits | 1757419200 | 1970 – 2286 | POSIX time_t, Python time.time(), Go time.Now().Unix(), PHP time(), Linux date +%s |
| Milliseconds (ms) | 13 digits | 1757419200000 | 1970 – 5138 | JavaScript Date.now(), Java System.currentTimeMillis(), Go time.Now().UnixMilli(), MongoDB ObjectId |
| Microseconds (μs) | 16 digits | 1757419200000000 | 1970 – 51380 | Python time.time_ns() // 1000, PostgreSQL TIMESTAMP, C++ std::chrono::microseconds |
| Nanoseconds (ns) | 19 digits | 1757419200000000000 | 1970 – 2262 (signed 64-bit) | Go time.Now().UnixNano(), Linux clock_gettime(CLOCK_REALTIME), OpenTelemetry, Jaeger |
The 1,000x Scale Trap in Production
Passing a millisecond timestamp (1757419200000) into an API expecting seconds projects the date into the year 57,000+. Conversely, passing seconds (1757419200) into JavaScript new Date(timestamp) parses the value as milliseconds, collapsing the date to January 21, 1970. Always check integer length before conversions.
POSIX Time Architecture: The 86,400-Second Standard
Leap Second Exclusion
The IEEE POSIX.1 specification mandates that every calendar day contains exactly 86,400 seconds:
Because UTC inserts leap seconds to compensate for Earth’s rotational variation, Unix time is not strictly linear International Atomic Time (TAI). When an official leap second occurs (such as 23:59:60 UTC), POSIX time repeats second 86,399, meaning the timestamp sequence is non-monotonic across that transition.
NTP Smearing in Cloud Infrastructure
Step clock resets during leap seconds risk race conditions, duplicate database keys, and distributed lock failures. Modern cloud providers (including AWS Time Sync Service and Google Public NTP) resolve this via Leap Smearing.
Instead of jumping the clock by 1 second, NTP servers gradually skew clock frequency by approximately 11.57 parts per million over a 24-hour window (12 hours before to 12 hours after the leap event), preserving strict monotonicity for application processes without operational downtime.
Database Storage Tradeoffs: Epoch Integer vs String vs Native Timestamp
Choosing between integer timestamps, ISO strings, and database-native types impacts index memory footprint, sorting performance, and timezone integrity.
| Storage Strategy | Database Type | Storage | B-Tree Indexing | Best Practical Application |
|---|---|---|---|---|
| Unix Seconds (INT) | INT / INTEGER (Signed 32-bit) | 4 Bytes | Fastest (32-bit integer numeric compare) | High-frequency telemetry, Redis keys, cache TTLs (Caution: hits signed 32-bit boundary in Y2038) |
| Unix Milliseconds (BIGINT) | BIGINT (Signed 64-bit) | 8 Bytes | Extremely fast (64-bit CPU register compare) | Kafka message offsets, distributed event streams, cross-language event sourcing pipelines |
| Native Database Timestamp | TIMESTAMPTZ (PostgreSQL) / DATETIME(6) (MySQL) | 8 Bytes | Fast (optimized binary B-Tree structure) | Relational business entities requiring calendar operations, grouping by month/day, and daylight awareness |
| ISO 8601 String | VARCHAR(24-35) / TEXT | 24–35 Bytes | Slow (lexicographical string comparisons) | Public REST/GraphQL payloads, JSON log sinks, audit trails where human readability without parsing is required |
The Year 2038 Problem (Y2038): Bitwise Overflow Mechanics
Signed 32-Bit Boundary
In 32-bit C systems, time_t is defined as a signed 32-bit integer. The maximum representable positive value is 2,147,483,647 (0x7FFFFFFF), reached on January 19, 2038, at 03:14:07 UTC.
Adding one second flips the sign bit to 0x80000000, wrapping the integer to -2,147,483,648 in two's complement notation. Legacy software interprets this as December 13, 1901, 20:45:52 UTC, causing logic errors in financial projections, SSL certificate validation, and cron triggers.
Migration & 64-Bit Immunity
64-bit systems utilize an 8-byte time_t with an upper bound of 9,223,372,036,854,775,807 seconds (~292 billion years).
Primary vulnerabilities remain in legacy infrastructure: MySQL tables using the 32-bit TIMESTAMP type (which hard-caps at 2038), 32-bit embedded Linux devices, compiled binaries compiled without -D_TIME_BITS=64, and binary network protocols using fixed 4-byte timestamp fields.
Key Unix Epoch Milestones Reference
| Epoch Seconds | Date & Time (UTC) | Significance |
|---|---|---|
| 0 | 1970-01-01 00:00:00 UTC | The Unix Epoch (Day Zero of POSIX time) |
| 1,000,000,000 | 2001-09-09 01:46:40 UTC | Unix Billenium milestone (first 10-digit epoch timestamp) |
| 1,500,000,000 | 2017-07-14 02:40:00 UTC | 1.5 Billion seconds since epoch |
| 2,000,000,000 | 2033-05-18 03:33:20 UTC | 2 Billion seconds milestone |
| 2,147,483,647 | 2038-01-19 03:14:07 UTC | Year 2038 Problem (Y2038): maximum signed 32-bit integer |
| 4,294,967,295 | 2106-02-07 06:28:15 UTC | Maximum unsigned 32-bit integer |
Developer Reference: Implementation Across Languages
Standard library patterns for retrieving current epoch timestamps and parsing Unix integers to UTC dates.
Math.floor(Date.now() / 1000) // seconds
Date.now() // millisecondsconst date = new Date(timestamp * 1000);
console.log(date.toISOString());
console.log(date.toUTCString());Core Applications in Production Systems
- RFC 7519 JWT Claims: Standard claims including
exp(expiration),iat(issued at), andnbf(not before) are defined strictly as integer epoch seconds. - In-Memory Cache Expiry: Redis commands like
EXPIREAT key timestampand Memcached TTL controls require absolute Unix timestamps for deterministic cache eviction. - HTTP Rate Limiting Headers: APIs return
X-RateLimit-Resetas an epoch integer so client libraries can calculate sleep intervals regardless of local clock drift. - Distributed Trace Spans: OpenTelemetry and Jaeger use 64-bit nanosecond timestamps to compute cross-service span durations and trace waterfall alignments.
Frequently Asked Questions
How do I convert a Unix timestamp to a readable date and time?
Paste the numeric timestamp into the input field. The converter automatically detects whether the value is in seconds, milliseconds, microseconds, or nanoseconds, and instantly displays the corresponding date in UTC, your local device timezone, standard ISO 8601 (YYYY-MM-DDTHH:mm:ssZ), and RFC 2822.
How can I tell if a timestamp is in seconds, milliseconds, microseconds, or nanoseconds?
Check the total digit count: 10 digits represent seconds (standard in Unix/POSIX, Python, PHP, and Go); 13 digits represent milliseconds (JavaScript Date.now() and Java); 16 digits represent microseconds (Python time_ns() // 1000 and database logs); and 19 digits represent nanoseconds (Go UnixNano and Linux kernel timespec).
Why does my converted date show January 1970?
This occurs when a 10-digit second timestamp (e.g. 1757419200) is passed directly to JavaScript new Date(timestamp). JavaScript expects milliseconds (13 digits), so it interprets 1.75 billion milliseconds as approximately 20.3 days past January 1, 1970. To fix this, multiply seconds by 1,000 before parsing: new Date(timestamp * 1000).
How do I convert a calendar date into a Unix timestamp?
Switch to the "Date → Timestamp" tab, select your calendar date and clock time, choose your target timezone (Local Device Time, UTC, or a specific UTC offset), and view the resulting Unix epoch timestamp in seconds and milliseconds.
Are Unix timestamps affected by time zones or Daylight Saving Time (DST)?
No. Unix timestamps are measured exclusively against UTC (Coordinated Universal Time) from the fixed epoch point (1970-01-01 00:00:00 UTC). A Unix timestamp represents the exact same absolute moment everywhere on Earth. Time zones and Daylight Saving Time are purely formatting offsets applied when presenting the timestamp to an end-user.
What is the Year 2038 Problem (Y2038)?
On January 19, 2038, at 03:14:07 UTC, signed 32-bit integer timestamps reach their maximum value of 2,147,483,647. The next second overflows into negative numbers (-2,147,483,648), resetting dates to December 13, 1901. Modern 64-bit systems are immune because a 64-bit integer timestamp can represent dates up to ~292 billion years in the future.
Can a Unix timestamp be a negative number?
Yes. Negative Unix timestamps represent moments before January 1, 1970. For example, -86400 represents December 31, 1969, at 00:00:00 UTC, and -315619200 represents January 1, 1960. The converter fully supports negative timestamps across all unit formats.
What is the difference between UTC, ISO 8601, and RFC 2822 date formats?
UTC is the universal reference time standard without time zone offsets. ISO 8601 (2026-09-16T12:00:00Z) is the international standard for software APIs and structured machine parsing. RFC 2822 (Wed, 16 Sep 2026 12:00:00 +0000) is the Internet Message Format standard used in email headers (SMTP/MIME), while HTTP headers (such as Last-Modified and Date) use the related RFC 7231 / RFC 1123 IMF-fixdate format (e.g. Wed, 16 Sep 2026 12:00:00 GMT).