Unix Timestamp Converter

A Unix timestamp (also called epoch time) is the number of seconds elapsed since January 1, 1970 00:00:00 UTC — used universally in programming to represent moments in time as a simple integer. To convert a Unix timestamp to a readable date online: paste the timestamp above and the equivalent date and time in UTC and local time appear instantly. To convert a date back to a Unix timestamp: enter the date and click Convert to Timestamp. The tool also shows the current epoch time live. Supports both seconds and milliseconds. All conversion runs in your browser.

What is Unix Time?

Unix Time (also known as Epoch Time) is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix Epoch, which is January 1st, 1970 at 00:00:00 UTC.

Why is it Used?

Computers prefer Unix timestamps because they are simple integers, making them easy to store, sort, and calculate differences between dates without worrying about time zones, leap years, or daylight saving time.

Key Advantages of Unix Timestamps

• Time Zone Independence: Unix timestamps are always in UTC, eliminating timezone ambiguity. Convert to local time only when displaying to users.
• Simple Arithmetic: Calculate time differences with basic subtraction: timestamp2 - timestamp1 gives you seconds elapsed.
• Database Efficiency: Timestamps are stored as integers, which are faster to index and query than datetime strings.
• Universal Standard: Works across all programming languages, databases, and systems without conversion.
• No DST Ambiguity: Since timestamps are in UTC, daylight saving time changes don't affect stored values.

Seconds vs. Milliseconds: 10-Digit vs. 13-Digit Timestamps

Unix timestamps come in two common formats, and understanding the difference is crucial for avoiding bugs.

10-Digit Timestamps (Seconds)

Example: 1672531200 represents January 1, 2023, 00:00:00 UTC.

This is the original Unix timestamp format, counting seconds since January 1, 1970. Most programming languages and databases use this format by default.

• Used by: Python's time.time(), PHP's time(), Unix shell date +%s
• Precision: 1 second (sufficient for most use cases)
• Storage: 32-bit signed integer (until 2038), 64-bit for future-proofing

13-Digit Timestamps (Milliseconds)

Example: 1672531200000 represents the same date, but with millisecond precision.

JavaScript's Date.now() and many APIs (like Twitter, Slack) use milliseconds for higher precision.

• Used by: JavaScript Date.now(), Java System.currentTimeMillis()
• Precision: 1 millisecond (needed for high-frequency events, like click tracking)
• Storage: 64-bit integer (required to fit millisecond values)

How to Convert Between Formats

// Seconds to Milliseconds
milliseconds = seconds * 1000

// Milliseconds to Seconds
seconds = Math.floor(milliseconds / 1000)

Common Mistake: Wrong Format Causes Year 1970 or 52,000 AD

If you pass a 10-digit timestamp to JavaScript's new Date(), it interprets it as milliseconds, resulting in a date in 1970. If you pass a 13-digit timestamp to a system expecting seconds, you'll get a date in the year 52,000.

How to detect: Check the length. 10 digits = seconds. 13 digits = milliseconds.

Timezone Handling Explained

Unix timestamps are always in UTC, but displaying them requires timezone conversion. Understanding this prevents common bugs.

Why Timestamps Are Always UTC

Unix timestamps represent a single moment in time, independent of location. 1672531200 represents January 1, 2023, 00:00:00 UTC—no matter where you are in the world. When you convert it to local time, you add or subtract hours based on your timezone offset.

UTC vs. Local Time

• UTC (Coordinated Universal Time): The worldwide time standard, with no daylight saving time adjustments.
• Local Time: Time adjusted for your timezone and daylight saving rules. For example, EST is UTC-5, PST is UTC-8.

Converting Timestamps to Local Time

When displaying timestamps to users, convert from UTC to their local timezone:

// JavaScript: Automatically converts to local time
const date = new Date(timestamp * 1000);
console.log(date.toLocaleString()); // "1/1/2023, 12:00:00 AM" (adjusted to local TZ)

// Python: Use pytz for timezone conversion
from datetime import datetime
import pytz
dt = datetime.fromtimestamp(timestamp, tz=pytz.UTC)
local_dt = dt.astimezone(pytz.timezone('America/New_York'))
print(local_dt.strftime('%Y-%m-%d %H:%M:%S'))

Storing Timestamps: Always Use UTC

Never store timestamps in local time. Always store in UTC (as Unix timestamps), and convert to local time only when displaying to users. This avoids issues when users change timezones or when daylight saving time starts/ends.

Daylight Saving Time (DST) and Timestamps

Unix timestamps are immune to DST confusion because they're in UTC. When clocks "spring forward" or "fall back," the timestamp remains unchanged. Only the local time representation changes.

Example: On March 12, 2023, at 2:00 AM in the U.S., clocks jumped to 3:00 AM (DST started). A timestamp of 1678593600 represents this moment. The UTC time didn't change—only the local time offset (from UTC-5 to UTC-4) changed.

The Year 2038 Problem (Y2K38)

On Tuesday, January 19, 2038, at 03:14:07 UTC, 32-bit Unix timestamps will overflow, potentially causing widespread software failures. This is known as the Year 2038 Problem or Y2K38.

Why It Happens

A 32-bit signed integer can store values from -2,147,483,648 to 2,147,483,647. Since Unix time counts seconds since January 1, 1970, the maximum representable date is 2,147,483,647 seconds after the epoch, which is January 19, 2038, at 03:14:07 UTC.

After this moment, the timestamp will overflow and wrap around to a negative number, resetting dates to December 13, 1901. This will break any system still using 32-bit timestamps.

Affected Systems

• Embedded Systems: IoT devices, routers, and industrial control systems often use 32-bit architectures.
• Legacy Databases: Older MySQL and PostgreSQL installations may store timestamps as 32-bit integers.
• Legacy Software: Applications written before 64-bit systems became standard.
• File Systems: Some file systems (like ext3) store timestamps as 32-bit values, limiting file modification dates.

The Solution: 64-Bit Timestamps

Modern systems use 64-bit timestamps, which can represent dates far into the future—approximately 292 billion years from the epoch. This effectively eliminates the overflow problem.

Example: A 64-bit timestamp can store values up to 9,223,372,036,854,775,807, which represents a date in the year 292,277,026,596. We're safe.

What You Should Do

• Check Your Systems: Audit databases, applications, and embedded systems to ensure they use 64-bit timestamps.
• Update Legacy Code: Migrate from time_t (32-bit) to int64_t or equivalent in your programming language.
• Test Before 2038: Set system clocks to January 19, 2038, and verify that applications don't crash or reset dates.
• Upgrade Operating Systems: Modern Linux distributions (post-2016) use 64-bit timestamps by default. Ensure you're on a recent OS version.

Programming Language Examples

Here's how to work with Unix timestamps in common programming languages:

JavaScript

// Get current timestamp (milliseconds)
const now = Date.now(); // 1672531200000

// Get current timestamp (seconds)
const nowSeconds = Math.floor(Date.now() / 1000); // 1672531200

// Convert timestamp to Date object
const date = new Date(1672531200 * 1000); // Multiply by 1000 for milliseconds

// Convert Date to timestamp
const timestamp = Math.floor(date.getTime() / 1000);

Python

import time
from datetime import datetime

# Get current timestamp (seconds)
now = time.time()  # 1672531200.123456

# Convert timestamp to datetime
dt = datetime.fromtimestamp(1672531200)

# Convert datetime to timestamp
timestamp = dt.timestamp()

# UTC-aware conversion
utc_dt = datetime.utcfromtimestamp(1672531200)

PHP

// Get current timestamp
$now = time(); // 1672531200

// Convert timestamp to date
$date = date('Y-m-d H:i:s', 1672531200);

// Convert date to timestamp
$timestamp = strtotime('2023-01-01 00:00:00');

MySQL

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1672531200); -- 2023-01-01 00:00:00

-- Convert datetime to timestamp
SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00'); -- 1672531200

-- Get current timestamp
SELECT UNIX_TIMESTAMP(); -- Current time

Java

// Get current timestamp (milliseconds)
long now = System.currentTimeMillis(); // 1672531200000

// Get current timestamp (seconds)
long nowSeconds = System.currentTimeMillis() / 1000; // 1672531200

// Convert timestamp to Date
Date date = new Date(1672531200L * 1000);

// Convert Date to timestamp
long timestamp = date.getTime() / 1000;

Common Timestamp Formats and Standards

While Unix timestamps are widely used, other date/time formats are also common in APIs and databases.

Unix Epoch (Seconds)

Example: 1672531200

The standard Unix timestamp format. Most systems default to this.

ISO 8601

Example: 2023-01-01T00:00:00Z

Human-readable, timezone-aware format used by REST APIs (like GitHub, Stripe). The Z indicates UTC.

RFC 3339

Example: 2023-01-01T00:00:00+00:00

Similar to ISO 8601, but explicitly shows timezone offset. Commonly used in JSON APIs.

RFC 2822

Example: Sun, 01 Jan 2023 00:00:00 +0000

Used in email headers and HTTP headers (like Date:).

Microsoft .NET Ticks

Example: 637104192000000000

100-nanosecond intervals since January 1, 0001. Used in C# and .NET applications.

Debugging Timezone Issues

Timezone bugs are notoriously difficult to debug. Here's how to troubleshoot common problems:

Problem: Timestamps are Off by a Few Hours

Cause: You're mixing UTC and local time. The timestamp is stored in UTC, but you're displaying it as if it were local (or vice versa).

Solution: Ensure you're consistently using UTC for storage and only converting to local time when displaying to users.

Problem: Dates Jump Forward/Backward During DST

Cause: You're storing timestamps in local time instead of UTC, so DST transitions cause apparent time jumps.

Solution: Always store timestamps in UTC. Convert to local time only when displaying.

Problem: Timestamps are in Milliseconds Instead of Seconds (or Vice Versa)

Cause: You're passing a 10-digit timestamp to a function expecting 13 digits, or vice versa.

Solution: Check the length. 10 digits = seconds. 13 digits = milliseconds. Convert as needed.

Problem: Dates Show as 1970 or Far-Future Years

Cause: You're using the wrong timestamp unit. Passing milliseconds to a function expecting seconds gives you a date in 1970. Passing seconds to a function expecting milliseconds gives you a date far in the future.

Solution: Verify whether your system expects seconds or milliseconds. Use Date.now() for milliseconds, Math.floor(Date.now() / 1000) for seconds.

Tools for Debugging

• Online Converters: Use tools like this one to verify timestamp conversions.
• Console Logging: Log both the timestamp and the converted date to verify they match expectations.
• Timezone Databases: Use libraries like moment-timezone (JavaScript) or pytz (Python) for accurate timezone handling.

Frequently Asked Questions

Why are there 10-digit and 13-digit timestamps?

10-digit timestamps represent seconds since January 1, 1970 (the Unix epoch). 13-digit timestamps represent milliseconds since the epoch. JavaScript uses milliseconds by default (Date.now()), while most other languages (Python, PHP, Unix shell) use seconds. To convert: multiply seconds by 1000 to get milliseconds, or divide milliseconds by 1000 to get seconds.

Does Daylight Saving Time (DST) affect Unix timestamps?

No. Unix timestamps are always in UTC, which doesn't observe daylight saving time. When clocks "spring forward" or "fall back," the timestamp remains unchanged—only the local time representation changes. This is why timestamps are reliable for time calculations: they're immune to DST confusion.

How do leap seconds work with Unix timestamps?

Unix time ignores leap seconds. When a leap second is added (like June 30, 2015, 23:59:60 UTC), Unix time "smears" it by slowing down time slightly over the surrounding minutes, rather than adding an extra second. This means Unix timestamps are not precisely astronomical time, but they're close enough for most applications. If you need true TAI (International Atomic Time), use specialized libraries.

Can Unix timestamps represent dates before 1970?

Yes, but with negative numbers. A timestamp of -86400 represents December 31, 1969 (one day before the epoch). However, some systems don't handle negative timestamps well, so dates before 1970 can be unreliable. For historical dates (like birthdates), consider using ISO 8601 date strings instead.

What happens in 2038?

On January 19, 2038, at 03:14:07 UTC, 32-bit signed integers used to store Unix timestamps will overflow, wrapping around to negative values. This will cause dates to reset to 1901, potentially breaking legacy systems. Modern 64-bit systems are unaffected and can represent dates for 292 billion years. Ensure your systems use 64-bit timestamps to avoid this issue.

Why do some APIs use different timestamp formats?

Different systems prioritize different trade-offs. Unix timestamps (seconds/milliseconds) are compact and efficient for storage. ISO 8601 (2023-01-01T00:00:00Z) is human-readable and self-documenting. RFC 3339 explicitly includes timezone offsets. APIs choose formats based on their use case: microservices often use Unix timestamps for speed, while REST APIs use ISO 8601 for clarity.

How do I convert between timezones?

Unix timestamps don't have timezones—they're always UTC. To "convert timezones," you convert the timestamp to a local datetime, then format it for display. In JavaScript: new Date(timestamp * 1000).toLocaleString('en-US', {timeZone: 'America/New_York'}). In Python: use pytz or dateutil to convert from UTC to a target timezone.

What's the difference between epoch time and uptime?

Epoch time: Time since January 1, 1970, 00:00:00 UTC (absolute time). Uptime: Time since a system was last rebooted (relative time). Epoch time is used for timestamps and scheduling. Uptime is used for monitoring server health. They're unrelated concepts, despite both being measured in seconds.

Can I use Unix timestamps for scheduling future events?

Yes, but with caution. For events within a few weeks or months, timestamps work well. For long-term events (years in the future), be aware that timezone rules and DST schedules can change. For example, if a government changes its DST policy, a stored timestamp representing "noon local time in 2030" might no longer be accurate. For critical scheduling, store both the timestamp and the intended timezone.

How do I test if my system will survive the Year 2038 Problem?

Set your system clock to January 19, 2038, 03:14:07 UTC and verify that applications don't crash or reset dates to 1901. Check database schemas to ensure timestamp columns use 64-bit integers (BIGINT in MySQL, TIMESTAMP in PostgreSQL post-2010). Audit code for time_t (32-bit) and replace with int64_t or language-specific 64-bit types.