Unix Timestamp Converter

Unix Timestamp Converter

Convert between Unix epoch timestamps and human-readable dates and times instantly. This tool is used daily by software developers debugging log files, database administrators reading stored timestamps, data analysts working with API response data, and anyone who needs to know exactly what moment a 10-digit number like 1746057600 represents.

How Unix Timestamp Conversion Works

A Unix timestamp is a count of seconds elapsed since the Unix epoch -- January 1, 1970, 00:00:00 UTC. Every second that passes increments the timestamp by 1.

Timestamp to date -- the total seconds are converted by dividing out years (accounting for 365 and 366-day leap years), then months (variable lengths), then days, hours, minutes, and remaining seconds. The result is always UTC; displaying local time requires adding or subtracting the time zone offset in seconds.

Date to timestamp -- sum all components from the epoch: years x 31,536,000 (adjusted for leap years) + month-days x 86,400 + hours x 3,600 + minutes x 60 + seconds. Example: January 1, 2025, 00:00:00 UTC = 1,735,689,600.

Seconds vs. milliseconds -- JavaScript's Date.now() and many REST APIs return milliseconds since epoch (a 13-digit number like 1,735,689,600,000). Standard Unix time uses seconds (10 digits). Divide milliseconds by 1,000 to get seconds; multiply seconds by 1,000 to get milliseconds.

Worked Examples

Example 1 -- Reading a server log. An nginx access log shows a request at timestamp 1700000000. Converting: 1,700,000,000 seconds / 86,400 = 19,675.9 days after Jan 1, 1970 = November 14, 2023, 22:13:20 UTC. In US Eastern time (UTC-5), that is November 14, 2023, at 5:13:20 PM.

Example 2 -- API rate limit header. A GitHub API response includes X-RateLimit-Reset: 1746057600. Converting: this is April 30, 2025, 16:00:00 UTC. If the current time is 15:45 UTC, the rate limit resets in 15 minutes.

Example 3 -- Database timestamp arithmetic. A user session stored in PostgreSQL started at created_at = 1735689600 and expired at 1735693200. The difference is 3,600 seconds = exactly 1 hour. Arithmetic on timestamps is a simple subtraction, no date library needed.

Reference Table

When to Use

• Decoding timestamps in server logs, crash reports, or monitoring dashboards where events are stored as integers.
• Converting API response fields (JWT expiry, OAuth token expiration, webhook timestamps) to readable dates for debugging.
• Generating a future or past Unix timestamp to use in a database query, API call, or scheduled job.
• Calculating the time difference between two events stored as Unix timestamps by subtracting one from the other.
• Verifying that a timestamp from a third-party system represents the date you expect before using it in production code.

Common Mistakes

1. Confusing seconds with milliseconds. A 10-digit timestamp like 1700000000 is seconds; a 13-digit timestamp like 1700000000000 is milliseconds. Treating a millisecond timestamp as seconds gives a date 1,000x further in the future -- the number 1700000000000 as seconds would be the year 55,000. Always check digit count: 10 digits = seconds, 13 digits = milliseconds.
2. Displaying UTC timestamps as local time without converting. A timestamp of 1700000000 is November 14, 2023, at 22:13:20 UTC. In New York (UTC-5 in November), it is 5:13 PM. Showing the UTC time to a New York user without labeling it UTC causes confusing 5-hour discrepancies.
3. Assuming all systems use the same timestamp precision. Python's time.time() returns seconds with fractional decimal places (e.g., 1700000000.123456). JavaScript's Date.now() returns integer milliseconds. MySQL's UNIX_TIMESTAMP() returns integer seconds. Mixing these without normalizing causes off-by-1 or off-by-1000 comparison bugs.
4. Ignoring negative timestamps. Unix timestamps before January 1, 1970 are negative. The timestamp -86400 is December 31, 1969, at 00:00:00 UTC. Some older systems and language libraries do not handle negative timestamps correctly and may return errors or wrong dates for any date before 1970.

Quick Reference Benchmarks

Useful constants for back-of-envelope timestamp math:

Tips

1. A 10-digit Unix timestamp starting with 17 is a date in late 2023 through approximately mid-2027. A timestamp starting with 16 is in 2020-2023. Use leading digits as a quick sanity check.
2. To get the current Unix timestamp: JavaScript -- Math.floor(Date.now() / 1000), Python -- int(time.time()), Bash -- date +%s, SQL (MySQL) -- UNIX_TIMESTAMP(), SQL (PostgreSQL) -- EXTRACT(EPOCH FROM NOW()).
3. To find the timestamp for midnight UTC on any date, enter the date at 00:00:00 UTC. Midnight timestamps are always divisible by 86,400.
4. Store all timestamps in your database as UTC. Convert to the user's local time zone only at the display layer. This prevents bugs when users change time zones or when daylight saving time transitions occur.
5. The Year 2038 problem affects 32-bit signed integer timestamps, which max out at 2,147,483,647 (January 19, 2038, 03:14:07 UTC). If your system still stores timestamps as 32-bit integers, plan migration to 64-bit integers before 2038.
6. When comparing two timestamps from different systems, verify they use the same epoch. Most systems use January 1, 1970, but Windows FILETIME uses January 1, 1601, and NTP uses January 1, 1900. Converting between epochs requires adding or subtracting the difference in seconds between the two reference dates.