Unix Timestamp Converter: What Epoch Time Is, How to Convert It, and the Y2K38 Problem

Every time you see a timestamp in an API response, a log file, or a JWT token, it is almost certainly a Unix timestamp - a simple integer counting the number of seconds (or milliseconds) since January 1, 1970, 00:00:00 UTC. This single integer represents any moment in time unambiguously, across every timezone, in a format that computers can compare and calculate with trivially. Unix timestamps power virtually all time-related data in modern software - from database records and server logs to scheduled jobs and authentication tokens. Understanding how they work, how to convert them, and the looming overflow issue that will affect 32-bit systems in 2038 is foundational knowledge for anyone working with APIs, databases, or backend code.

A Unix timestamp is the number of seconds elapsed since the Unix epoch - midnight on January 1, 1970, in Coordinated Universal Time (UTC). This point in time was chosen by the early Unix engineers at Bell Labs as a convenient reference point for the systems they were building in the late 1960s and early 1970s. The specific date was chosen because it was recent enough to produce small, manageable integer values for dates in the foreseeable future, while being far enough in the past to represent historical dates from the preceding decade. The choice was practical, not philosophically significant.

The current Unix timestamp as of this writing is above 1.7 billion seconds. That number increases by exactly 86,400 each day (60 seconds x 60 minutes x 24 hours). Because Unix timestamps are just integers, date comparison reduces to integer comparison: timestamp A is before timestamp B if and only if A is less than B. Date arithmetic - how many seconds between two events, when does this token expire, is this record older than 30 days - reduces to simple subtraction.

The Unix standard uses seconds as its base unit. Most Unix/Linux system calls, POSIX standards, databases (MySQL's UNIX_TIMESTAMP, PostgreSQL's EXTRACT(EPOCH)), and server-side languages use seconds. JavaScript is a significant exception: `Date.now()` returns milliseconds since epoch, and `new Date(timestamp)` expects milliseconds. This discrepancy causes real bugs: a Unix timestamp in seconds passed to JavaScript's Date constructor produces a date in January 1970 because JavaScript interprets the seconds value as if it were milliseconds (dividing it by 1000 notionally).

The rule to remember: Unix = seconds. JavaScript = milliseconds. To convert a Unix timestamp (seconds) to a JavaScript Date: `new Date(unixTimestamp * 1000)`. To get the current Unix timestamp in JavaScript: `Math.floor(Date.now() / 1000)`. To get milliseconds from a Unix timestamp for Date.now() comparisons: `unixTimestamp * 1000`.

Timestamp conversion is a daily task in development. Here are the idiomatic approaches in the three most commonly used contexts.

• JavaScript - current timestamp: `Math.floor(Date.now() / 1000)` returns the current Unix timestamp in seconds. `Date.now()` returns milliseconds; divide by 1000 and floor to get whole seconds.
• JavaScript - timestamp to Date object: `new Date(unixSeconds * 1000)` constructs a Date object from a seconds timestamp. From there: `.toISOString()` for ISO 8601 format, `.toLocaleDateString()` for locale-appropriate display.
• Python - current timestamp: `import time; int(time.time())` returns the current Unix timestamp in seconds as an integer. `time.time()` returns a float including fractional seconds.
• Python - timestamp to datetime: `from datetime import datetime; datetime.fromtimestamp(ts)` converts a Unix timestamp to a local datetime. Use `datetime.utcfromtimestamp(ts)` for a UTC datetime without timezone info, or `datetime.fromtimestamp(ts, tz=timezone.utc)` for a timezone-aware UTC datetime (the recommended approach for modern Python code).
• MySQL - timestamp to readable date: `SELECT FROM_UNIXTIME(unix_timestamp)` converts a stored integer timestamp to a MySQL DATETIME. `SELECT UNIX_TIMESTAMP(datetime_column)` converts in the other direction.
• PostgreSQL: `SELECT to_timestamp(unix_timestamp)` converts to a TIMESTAMPTZ. `SELECT EXTRACT(EPOCH FROM timestamp_column)` converts a timestamp to Unix epoch seconds.

Unix timestamps appear in virtually every software system that stores or transmits time data. Recognising them in the wild is a useful skill.

• Log files. Server access logs, application logs, and error logs almost universally use Unix timestamps for each entry. They sort naturally (higher timestamp = later event), and log analysis tools can compare timestamps with simple arithmetic.
• REST API responses. APIs frequently return timestamps as integers rather than formatted date strings - simpler to serialize, unambiguous in any timezone, and parseable by every client language. When you see a field named `created_at: 1717200000` in a JSON response, it is a Unix timestamp in seconds.
• Database storage. Storing dates as Unix timestamps (integers) in databases is common for performance: integer columns are faster to index and compare than DATETIME columns in many database engines.
• JWT token expiry. JSON Web Tokens use the `exp` (expiration) and `iat` (issued at) claims as Unix timestamps in seconds. A token with `exp: 1717286400` expires at that specific second. Use the JWT Decoder at /tools/jwt-decoder-validator to decode and inspect JWT tokens and see their expiry timestamps in human-readable form.
• Event scheduling and cron jobs. Scheduled tasks often store their next-run time as a Unix timestamp for easy comparison: if current_time > next_run_time, execute the job. The Cron Expression Generator at /tools/cron-expression-generator generates cron syntax for scheduling recurring tasks.
• Version control. Git commit timestamps are Unix timestamps internally. `git log --format='%ct'` outputs commit times as Unix timestamps.

The Y2K38 problem (also called the Unix Year 2038 problem or Y2038) is a real overflow issue for 32-bit systems. A 32-bit signed integer can hold values from -2,147,483,648 to 2,147,483,647. The maximum value - 2,147,483,647 - corresponds to January 19, 2038, at 03:14:07 UTC. One second later, the integer overflows and wraps to -2,147,483,648, which corresponds to December 13, 1901. Any 32-bit system that stores time as a 32-bit signed integer and has not been updated will experience this overflow.

Modern 64-bit systems store Unix timestamps as 64-bit integers, which can hold values up to 9,223,372,036,854,775,807. This maximum corresponds to a date approximately 292 billion years from now - effectively infinite for any practical computing purpose. The Y2K38 problem is not a concern for any modern operating system or programming language running on 64-bit hardware. It remains a concern for embedded systems, legacy industrial control systems, and old 32-bit applications that have not been updated. The Linux kernel migrated 32-bit time_t to 64-bit in 2020 specifically to address this. More information on the scope of affected systems is available at y2038.com.

Unix timestamps are always UTC. The timestamp 1717200000 represents the same absolute moment in time everywhere in the world. What differs is the local representation of that moment: in UTC it is 2024-06-01 00:00:00, in New York (UTC-4 during EDT) it is 2024-05-31 20:00:00, in Tokyo (UTC+9) it is 2024-06-01 09:00:00. The timestamp itself does not contain timezone information. Timezone conversion happens at the display layer, not the storage layer.

This is why storing and transmitting timestamps as Unix integers is safer than storing formatted date strings with implied timezones. A string like '2024-06-01 00:00:00' is ambiguous without a timezone suffix. The ISO 8601 format with UTC suffix ('2024-06-01T00:00:00Z') is unambiguous. A Unix timestamp is unambiguous by definition. For date arithmetic across timezones - how many days between two events in users' local times - use a proper timezone-aware library (Python's zoneinfo module, JavaScript's Temporal API, or date-fns) rather than raw Unix arithmetic, because timezone offsets and daylight saving transitions affect the day boundary.

When consuming REST APIs, timestamps in responses are almost always either Unix seconds, Unix milliseconds, or ISO 8601 strings. A quick heuristic: a 10-digit integer is Unix seconds; a 13-digit integer is Unix milliseconds; a string starting with a 4-digit year is ISO 8601. When building APIs, the convention among modern REST APIs (including Google, Twitter, and GitHub's API) is to return timestamps as ISO 8601 strings with UTC suffix ('2024-06-01T12:00:00Z'). This is more human-readable than Unix integers and unambiguous, at the cost of a few extra bytes.

JWT tokens use Unix timestamps in seconds for the `exp` (expiration) and `iat` (issued at) standard claims. A common security check is verifying that `exp > current_time` before trusting a token. The JWT Decoder at /tools/jwt-decoder-validator decodes any JWT token and shows the exp and iat values converted to human-readable date strings, making token debugging much faster. For date difference calculations - how many days between two timestamps, when does this subscription expire - use the Date Difference Calculator at /tools/date-difference-calculator.

The Unix Timestamp Converter at /tools/unix-timestamp-converter converts between Unix timestamps and human-readable dates in both directions. Here is the workflow.

1. Open the tool at seosearchlight.com/tools/unix-timestamp-converter
2. To convert a timestamp to a date: paste the integer value into the timestamp field and select seconds or milliseconds
3. The tool displays the corresponding UTC datetime and local datetime (based on your browser timezone)
4. To convert a date to a timestamp: enter the date and time in the date picker and select your timezone
5. The tool outputs both the Unix seconds and milliseconds equivalents
6. The current timestamp is displayed live so you can reference it or copy it for use in code
7. For JWT token expiry fields, paste the exp value directly - the tool accepts both seconds and milliseconds