Epoch Converter
Convert Unix timestamps to human-readable dates and vice versa
Enter a timestamp or select a date
Enter a timestamp or select a date
Epoch time, also known as Unix timestamp, 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 1, 1970, 00:00:00 Coordinated Universal Time (UTC), minus leap seconds.
It is widely used in computing and programming because it simplifies date and time calculations and storage. Instead of dealing with timezones, daylight saving time, leap years, and varying month lengths, you can represent any moment in time as a single number.
Why January 1, 1970? This date was chosen as the Unix epoch because it was close to the time Unix was being developed and provided a convenient round number for calculations. It predates most computing systems, ensuring compatibility.
This tool automatically detects the format of your timestamp (seconds, milliseconds, microseconds, or nanoseconds) and converts it to a human-readable UTC time format. It also supports converting dates back to timestamps for use in your applications.
- Timestamp to Date: Paste your Unix timestamp into the input field. The tool will automatically detect its precision (seconds, milliseconds, microseconds, or nanoseconds) and convert it instantly to UTC time. The format detection is intelligent - you don't need to specify the precision manually.
- Date to Timestamp: Use the date and time picker to select a specific date and time. The tool will instantly convert it to a Unix timestamp in seconds. This is useful for creating scheduled tasks, API requests, or database queries.
- Current Timestamp: Click the "Current Time" card to use the live timestamp as input. This is helpful for testing or getting a quick reference point.
- Copy Results: Use the convenient copy buttons next to each output value to quickly grab the converted data for your code or documentation.
- Comma Support: Commas in timestamps (e.g., "1,234,567,890") are automatically removed for easy copy-pasting from spreadsheets or formatted displays.
- API Debugging: Quickly convert timestamps from API responses or webhooks to understand event times and verify timing issues.
- Log Analysis: Transform server log timestamps into readable formats for easier debugging and analysis. Essential for tracking errors and performance issues.
- Database Management: Work with timestamp fields in databases, converting them to and from Epoch for queries, migrations, and data analysis.
- System Synchronization: Ensure consistent timekeeping across different systems by converting timestamps to a common format that works regardless of timezone.
- Data Migration: Handle timestamp conversions during data import or export processes, especially when moving between different database systems.
- Forensics & Auditing: Analyze file system or network event timestamps to reconstruct event timelines and investigate security incidents.
- JWT Tokens: Decode exp (expiration) and iat (issued at) claims in JSON Web Tokens to verify token validity and lifetime.
- Scheduling: Convert human-readable dates to Unix timestamps for cron jobs, task schedulers, or reminder systems.
- Performance Monitoring: Calculate time differences between events using millisecond-precision timestamps for performance profiling.
- Cache Expiration: Set and check cache expiration times using Unix timestamps for efficient cache management.
The #1 timestamp bug developers encounter is mixing up seconds and milliseconds. JavaScript uses milliseconds, most backend languages use seconds, and this causes confusion.
🚨 Common Error
Passing JavaScript milliseconds to a backend API expecting seconds:
WRONG (JavaScript):
const timestamp = Date.now();
// 1708300800000 (13 digits)
// Backend expects seconds!CORRECT:
const timestamp = Math.floor(Date.now() / 1000);
// 1708300800 (10 digits)
// Now in seconds ✓Quick Detection Guide:
- 10 digits: Seconds (1234567890) → Valid until 2286
- 13 digits: Milliseconds (1234567890123) → JavaScript's Date.now()
- 16 digits: Microseconds → Scientific/High-frequency systems
- 19 digits: Nanoseconds → Kernel/Ultra-precise timing
Pro Tip: If your date shows up as 1970-01-16 instead of 2024, you're treating milliseconds as seconds. If it shows year 50000+, you're treating seconds as milliseconds.
Different programming languages have different conventions for working with Unix timestamps. Here's how to get current timestamps and convert between formats:
● JavaScript
// Get current timestamp (milliseconds)
const ms = Date.now(); // 1708300800000
// Convert to seconds (for backend APIs)
const seconds = Math.floor(Date.now() / 1000);
// Convert timestamp to Date object
const date = new Date(1708300800 * 1000); // ×1000 for seconds
console.log(date.toISOString()); // "2024-02-19T04:00:00.000Z"● Python
import time
from datetime import datetime
# Get current timestamp (seconds)
timestamp = time.time() # 1708300800.123456
# Convert timestamp to datetime
dt = datetime.fromtimestamp(1708300800)
print(dt) # 2024-02-19 04:00:00
# Convert datetime to timestamp
ts = int(datetime(2024, 2, 19, 4, 0, 0).timestamp())● PHP
<?php
// Get current timestamp (seconds)
$timestamp = time(); // 1708300800
// Convert timestamp to date
$date = date('Y-m-d H:i:s', 1708300800);
// "2024-02-19 04:00:00"
// Convert date string to timestamp
$ts = strtotime('2024-02-19 04:00:00');
?>● Java
// Get current timestamp (milliseconds)
long ms = System.currentTimeMillis();
// Convert to seconds
long seconds = System.currentTimeMillis() / 1000;
// Convert timestamp to Date
Date date = new Date(1708300800L * 1000);
// Using Java 8+ Instant
Instant instant = Instant.ofEpochSecond(1708300800);● SQL
-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW()); -- Current timestamp
SELECT TO_TIMESTAMP(1708300800); -- Convert to datetime
-- MySQL
SELECT UNIX_TIMESTAMP(); -- Current timestamp
SELECT FROM_UNIXTIME(1708300800); -- Convert to datetimeImportant: Unix timestamps are always in UTC (Coordinated Universal Time) and are timezone-independent. A timestamp represents the same moment in time worldwide - only the display format changes based on your local timezone.
Example: Same Timestamp, Different Local Times
Timestamp: 1609459200 (January 1, 2021, 00:00:00 UTC)
- London (GMT/UTC+0): 2021-01-01 00:00:00
- India (IST/UTC+5:30): 2021-01-01 05:30:00
- New York (EST/UTC-5): 2020-12-31 19:00:00 (previous day!)
- Los Angeles (PST/UTC-8): 2020-12-31 16:00:00
- Tokyo (JST/UTC+9): 2021-01-01 09:00:00
- Sydney (AEDT/UTC+11): 2021-01-01 11:00:00
🕐 Daylight Saving Time (DST) Issues
DST causes these problems when working with timestamps:
- Spring Forward: One hour is skipped (e.g., 2 AM → 3 AM). Creating timestamps for that hour can fail or produce unexpected results.
- Fall Back: One hour repeats (e.g., 2 AM happens twice). Converting local time to timestamp becomes ambiguous.
- Database Confusion: Storing local times instead of UTC timestamps makes historical data analysis inconsistent.
- API Mismatches: Clients in different timezones or DST states can send inconsistent data.
Solution: Always store UTC timestamps in your database. Convert to local time only when displaying to users.
Best Practices for Timezone Handling:
- Store UTC timestamps: Use Unix epoch timestamps in your database. Never store local times unless absolutely necessary.
- Convert at display time: Transform timestamps to user's local timezone only when rendering UI.
- Use UTC for logs: All server logs should use UTC timestamps for consistency across distributed systems.
- Test DST transitions: When testing scheduling features, verify behavior during DST changes (March and November in US/Europe).
- Communicate timezone clearly: When displaying timestamps, always show the timezone (e.g., "2024-02-19 10:00 AM EST").
- Use ISO 8601 format: For human-readable timestamps, use ISO 8601 (2024-02-19T10:00:00Z) which explicitly shows UTC with the Z suffix.
⚠️ Year 2038 Problem (32-bit Integer Overflow)
On January 19, 2038 at 03:14:07 UTC, the timestamp will exceed 2,147,483,647 (maximum value for signed 32-bit integer). Systems still using 32-bit timestamps will overflow and wrap back to 1901.
Max 32-bit timestamp: 2147483647 → January 19, 2038, 03:14:07 UTC
Next timestamp: 2147483648 → Overflows to December 13, 1901!
Solution: Modern 64-bit systems support timestamps until year 292 billion+. Verify your database columns and system libraries use 64-bit integers. MySQL's INT columns should be BIGINT, and C programs should use time64_t.
⚠️ Leap Seconds
Unix time ignores leap seconds, which are occasionally added to UTC to account for Earth's irregular rotation. Since 1972, 37 leap seconds have been added, creating a 37-second discrepancy between Unix time and true UTC.
Impact: For most applications, this difference is negligible. However, for ultra-precise timing (GPS, astronomy, financial trading), be aware that Unix timestamps don't perfectly align with UTC. Use specialized time libraries if sub-second precision matters.
⚠️ Precision Confusion
Always verify whether your timestamp is in seconds, milliseconds, or another precision. A common mistake is treating milliseconds as seconds.
1234567890 (10 digits) → February 14, 2009 ✓
1234567890123 (13 digits) → February 14, 2009 ✓
1234567890 treated as ms → January 15, 1970 ✗ (WRONG)
1234567890123 treated as s → Year 41130 ✗ (WRONG)
Additional Common Mistakes:
- Forgetting to multiply by 1000: When passing seconds to JavaScript's Date constructor, you must multiply by 1000:
new Date(timestamp * 1000) - Using local time for storage: Always store UTC timestamps. Converting local time to timestamp can fail during DST transitions.
- Comparing timestamps as strings: "1234567890" > "234567890" is true as strings, but numerically 234567890 is less than 1234567890. Always compare as numbers.
- Not validating timestamp ranges: Check if timestamps are reasonable (e.g., between 1970 and 2100) to catch precision errors early.
- Hardcoding timezone offsets: Never hardcode UTC+5 or similar. Offsets change due to DST. Use proper timezone libraries.
Unix timestamps come in different precisions depending on the system and use case. This tool automatically detects the precision based on the number of digits:
Seconds (10 digits)
1234567890Used by: Most Unix/Linux systems, databases (MySQL, PostgreSQL), Python's time.time(), PHP's time(), Go's time.Now().Unix()
Precision: 1 second. Suitable for most applications including logging, scheduling, and general timekeeping.
Range: Valid until year 2286 (for unsigned 32-bit) or 2038 (for signed 32-bit)
Milliseconds (13 digits)
1234567890123Used by: JavaScript's Date.now(), Java's System.currentTimeMillis(), .NET's DateTimeOffset.ToUnixTimeMilliseconds()
Precision: 1 millisecond (0.001 seconds). Essential for performance monitoring, event timing, and analytics.
Common issue: Forgetting to divide by 1000 when sending to backend APIs that expect seconds.
Microseconds (16 digits)
1234567890123456Used by: Go's time.Now().UnixMicro(), high-precision database logs, scientific computing, profiling tools
Precision: 1 microsecond (0.000001 seconds). Required for performance profiling, financial systems, and distributed tracing.
Use case: Measuring function execution time, analyzing network latency, high-frequency trading systems.
Nanoseconds (19 digits)
1234567890123456789Used by: Linux kernel timestamps, Go's time.Now().UnixNano(), high-frequency trading, hardware timestamping
Precision: 1 nanosecond (0.000000001 seconds). Ultra-precise timing for kernel operations and performance-critical applications.
Limitation: Most system clocks don't actually provide true nanosecond accuracy, but the format allows for consistent representation.
100% Client-Side Processing: All timestamp conversions happen entirely in your browser using JavaScript. No data is sent to any server, ensuring your timestamps and dates remain completely private. This is especially important when working with sensitive scheduling data, analyzing private logs, or handling confidential business information.
No Data Storage or Tracking: This tool doesn't store any history of your conversions or track your usage. Every time you refresh the page, you start with a clean slate. Your conversion history exists only in your browser's memory during your current session and is discarded when you close the tab.
Open Source & Transparent: You can inspect the tool's source code directly in your browser's developer tools. There are no hidden network requests or data collection mechanisms.
Best Security Practices: When working with authentication tokens or session timestamps, always verify expiration times properly. Use this tool to debug JWT token expiration (exp claim) and ensure your tokens have appropriate lifetimes (typically 15 minutes to 1 hour for access tokens, longer for refresh tokens).