Unix Timestamp Converter

A Unix Timestamp Converter is a tool that converts between Unix timestamps (also called Epoch time or POSIX time) and human-readable date and time formats. Unix timestamp represents the number of seconds or milliseconds that have elapsed since January 1, 1970, 00:00:00 UTC, known as the Unix Epoch. This numeric format is widely used in programming, databases, and APIs because it is timezone-independent, easy to compare, and simple to perform arithmetic on. Whether you are analyzing server logs, debugging API responses, or working with database records, this converter helps you quickly translate between machine-friendly timestamps and readable dates.

User Guide

1. Check the real-time Unix timestamp displayed in the "Current Time" section at the top.
2. To convert a timestamp to a date, enter the numeric value and click "Convert" or press Enter.
3. Use the unit selector (Auto, Seconds, Milliseconds) to specify the format or let the tool auto-detect.
4. Use the quick buttons (Now, 0, 1B, 2B) to instantly convert commonly referenced values.
5. To convert a date to a timestamp, fill in the year, month, day, hour, minute, and second fields, then click "Convert".
6. Copy any result using the copy buttons next to each output value.

Core Features

• Bidirectional conversion between timestamps and human-readable dates
• Auto-detection of seconds (10-digit) and milliseconds (13-digit) formats
• Real-time display of the current Unix timestamp
• Quick conversion buttons (Now, 0, 1B, 2B) for commonly used values
• Multiple output formats: ISO 8601, UTC, local time, and relative time
• Support for both local timezone and UTC
• One-click copy for any converted result

When This Comes in Handy

• Reading timestamps recorded in server logs and error reports
• Converting created_at and updated_at fields from REST API responses
• Preparing date values as timestamps for database storage
• Checking the expiration time (exp claim) of JWT tokens
• Debugging time synchronization issues between servers in different timezones
• Verifying scheduled execution times for cron jobs and task schedulers

Classic Timestamp Bugs, With Code

The 1970 bug: seconds fed to a milliseconds API. JavaScript's Date constructor expects milliseconds, so passing a seconds-based value straight from a backend gives new Date(1704067200) — which renders as January 20, 1970 instead of January 1, 2024. The fix is new Date(1704067200 * 1000). The mirror-image bug also exists: sending Date.now() (13 digits) to an API that stores seconds produces dates tens of thousands of years in the future. Whenever a UI shows a date suspiciously close to 1970, check the unit first; this converter's auto-detect (10 vs 13 digits) is a quick way to confirm which unit you are holding.

The silent timezone shift in date-string parsing. In JavaScript, new Date("2024-01-15") is parsed as midnight UTC, while new Date(2024, 0, 15) is midnight local time — two different timestamps for what looks like the same date. For a user in UTC+9 the first form displays as 9:00 AM, and for a user in a negative-offset timezone it can even display as January 14. When a "date only" value drifts by a day in production, compute the expected timestamp here with the timezone selector set to both Local and UTC, and compare against what your code produced.

Mixed units inside one dataset. Migrations and multi-language stacks often leave a table where older rows store seconds (from PHP's time()) and newer rows store milliseconds (from System.currentTimeMillis()). Sorting or comparing across that boundary silently misorders events by a factor of 1000. Spot-checking a few suspect values in this converter — a 10-digit value landing in a sane year while a 13-digit neighbor lands in 55000 AD when read as seconds — is the fastest way to diagnose the mix.

Common Questions