Unix Timestamp Converter

**What Is a Unix Timestamp?** A Unix timestamp (also called epoch time or POSIX time) is a single integer that represents the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC — a reference point known as the Unix epoch. This standard was defined in the POSIX specification and is used by virtually every operating system, programming language, and web service on the planet. As of early 2024, the current Unix timestamp is approximately 1,706,000,000 — a number that increments by exactly 1 every second, 86,400 every day. Why does this matter? Because timestamps are language-neutral and timezone-neutral. A Unix timestamp of 1706745600 means the exact same moment everywhere on Earth — whether you're reading it in a Node.js API response in New York, a Python script on an AWS Lambda in Virginia, or a MySQL database log in California. Human-readable date strings like "February 1, 2024" are ambiguous without timezone context; Unix timestamps are not. **Step-by-Step: How to Use the Timestamp Converter** Using this tool is straightforward. Here's the typical workflow: 1. **Convert timestamp to date**: Paste or type a Unix timestamp into the input field. For example, enter 1706745600. The tool instantly displays: Thursday, February 1, 2024 00:00:00 UTC. You'll also see the equivalent local time based on your browser's timezone. 2. **Convert date to timestamp**: Switch to date input mode, enter a date and time (for example, March 15, 2024 09:00:00 AM Eastern Time), and the tool outputs the corresponding Unix timestamp: 1710507600. 3. **Handle milliseconds**: If your timestamp has 13 digits (for example, 1706745600000), it's in milliseconds — commonly used in JavaScript. Paste it in and the tool auto-detects the unit and converts correctly. 4. **Copy the result**: Click the copy button to grab the converted value for use in your terminal, code editor, or database query. **Timestamp Precision: Detecting Seconds, Milliseconds, Microseconds, and Nanoseconds** Not all Unix timestamps use the same unit. There are four common precisions, each identifiable by digit count: | Digits | Unit | Example | Primary source | |---|---|---|---| | 10 | Seconds | 1706745600 | Standard Unix — Stripe, GitHub, POSIX APIs | | 13 | Milliseconds | 1706745600000 | JavaScript Date.now(), Java System.currentTimeMillis() | | 16 | Microseconds | 1706745600000000 | Python datetime × 1e6, PostgreSQL EXTRACT microseconds | | 19 | Nanoseconds | 1706745600000000000 | Go time.Now().UnixNano(), precision scientific logging | Rule of thumb: count the digits. 10 = seconds, 13 = milliseconds, 16 = microseconds, 19 = nanoseconds. If you pass a 13-digit millisecond value to a function expecting seconds, the computed date will land in the year 55,000 — a classic production bug. Always verify with this converter during integration testing. **Real-World Examples Every Developer Encounters** Unix timestamps appear constantly in backend development. Here are four scenarios you'll recognize: **AWS CloudWatch Logs**: CloudWatch returns log events with a timestamp field in milliseconds. If you see `"timestamp": 1706745600123`, divide by 1,000 to get 1706745600.123 seconds, which maps to February 1, 2024 at 00:00:00.123 UTC. AWS bills per hour and rotates log groups by time — knowing the human-readable equivalent is essential for debugging. **REST API Responses**: GitHub's API returns created_at and updated_at as ISO 8601 strings, but many APIs — especially payment processors and analytics platforms — return Unix timestamps. Stripe's API, for example, returns `"created": 1706745600` on charge objects. When you're debugging a payment discrepancy, quickly converting that to "February 1, 2024" saves you from mental arithmetic under pressure. **JavaScript Date.now()**: In the browser and Node.js, `Date.now()` returns milliseconds since epoch. If you log `console.log(Date.now())` in Node 20, you'll get something like 1706745600000. Divide by 1,000 to get the standard Unix timestamp in seconds. This is one of the most common sources of the off-by-1000 bug. **Database Timestamps**: MySQL's `UNIX_TIMESTAMP()` function and PostgreSQL's `EXTRACT(EPOCH FROM NOW())` both return seconds. SQLite stores timestamps as integers or text — if you're storing Unix timestamps in SQLite for a mobile app's local database, this converter helps you verify your records during development. **Timestamp Format Comparison Table** | Format | Example | Timezone-safe? | Language support | Sortable? | |---|---|---|---|---| | Unix timestamp (seconds) | 1706745600 | Yes | Universal | Yes | | Unix timestamp (milliseconds) | 1706745600000 | Yes | JavaScript native | Yes | | ISO 8601 | 2024-02-01T00:00:00Z | Yes (with Z) | Wide | Yes | | RFC 2822 | Thu, 01 Feb 2024 00:00:00 +0000 | Yes | Email/HTTP | No | | US locale string | 2/1/2024 12:00:00 AM | No | Browser-only | No | | Human readable | February 1, 2024 | No | Display only | No | For storage and comparison, Unix timestamps and ISO 8601 with UTC offset are the two professional-grade options. Unix timestamps have a slight edge for database indexing (integer comparison is faster than string comparison) and for serialization across systems. **Time Unit Quick Reference** Knowing how many seconds are in common time intervals is essential for timestamp arithmetic — cache TTL settings, session expiry, rate-limit windows, and subscription billing all rely on these: | Time unit | Seconds | |---|---| | 1 minute | 60 | | 1 hour | 3,600 | | 1 day | 86,400 | | 1 week | 604,800 | | 30 days | 2,592,000 | | 1 year (365 days) | 31,536,000 | | 1 year (365.25-day average) | 31,557,600 | Example: to check whether a cached API response is stale after 24 hours, compare `current_timestamp - cached_timestamp > 86400`. This is faster than parsing date strings and works identically in every language. **Language-Specific Timestamp Conversions** Here's how to convert timestamps in the most common languages — handy reference for when you're writing the code after using this tool to verify the expected output: **JavaScript / Node.js:** ```js // Timestamp to date new Date(1706745600 * 1000).toISOString() // "2024-02-01T00:00:00.000Z" // Date to timestamp Math.floor(new Date('2024-02-01').getTime() / 1000) // 1706745600 ``` **Python:** ```python from datetime import datetime, timezone # Timestamp to date datetime.fromtimestamp(1706745600, tz=timezone.utc) # datetime(2024, 2, 1, 0, 0, tzinfo=timezone.utc) # Date to timestamp import calendar; calendar.timegm((2024, 2, 1, 0, 0, 0, 0, 0, 0)) # 1706745600 ``` **SQL (PostgreSQL):** ```sql SELECT TO_TIMESTAMP(1706745600); -- 2024-02-01 00:00:00+00 SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-02-01 00:00:00 UTC'); -- 1706745600 ``` **Extended Language Examples** **Go:** ```go import "time" // Timestamp to date t := time.Unix(1706745600, 0).UTC() // 2024-02-01 00:00:00 +0000 UTC // Date to timestamp ts := time.Date(2024, 2, 1, 0, 0, 0, 0, time.UTC).Unix() // 1706745600 // Nanosecond precision tsNano := time.Now().UnixNano() // 19-digit integer ``` **Java:** ```java import java.time.Instant; // Timestamp to date Instant.ofEpochSecond(1706745600L) // 2024-02-01T00:00:00Z // Date to timestamp Instant.parse("2024-02-01T00:00:00Z").getEpochSecond() // 1706745600 // Milliseconds (Java standard) System.currentTimeMillis() // 13-digit ms timestamp ``` **PHP:** ```php // Timestamp to date date('Y-m-d H:i:s', 1706745600); // "2024-02-01 00:00:00" // Date to timestamp strtotime('2024-02-01 00:00:00 UTC'); // 1706745600 ``` **MySQL:** ```sql -- Timestamp to date SELECT FROM_UNIXTIME(1706745600); -- '2024-02-01 00:00:00' -- Date to timestamp SELECT UNIX_TIMESTAMP('2024-02-01 00:00:00'); -- 1706745600 ``` **Common Mistakes That Cause Real Bugs** **Mistake 1 — Milliseconds vs. seconds confusion**: The single most common timestamp bug in JavaScript. `Date.now()` returns 1706745600000 (13 digits), but Unix standard is 1706745600 (10 digits). If you pass a millisecond timestamp to a Python `datetime.fromtimestamp()` call expecting seconds, you'll get a date in the year 55,000 CE. Always check digit count: 10 digits = seconds, 13 digits = milliseconds. **Mistake 2 — Treating timestamps as local time**: Unix timestamps are always UTC. If you do `new Date(timestamp)` in JavaScript in New York (UTC-5), the `.toString()` output shows EST — but the timestamp itself is UTC. When storing in a database, always store UTC and convert at display time. **Mistake 3 — The Year 2038 Problem**: 32-bit signed integers max out at 2,147,483,647, which corresponds to January 19, 2038 03:14:07 UTC. Legacy C systems and older MySQL INT(11) columns storing timestamps will overflow on that date. Modern systems use 64-bit integers, which extend the range to the year 292 billion — effectively infinite. If you're auditing a legacy codebase, check for `int` vs `bigint` timestamp columns. **Mistake 4 — Assuming all APIs use the same unit**: Stripe uses seconds. Twilio uses ISO 8601. Salesforce uses milliseconds. Slack uses seconds with fractional parts (e.g., 1706745600.123456). Always read the API documentation for the specific service. Use this converter to spot-check your parsed values against expected dates during integration testing. **Mistake 5 — Ignoring leap seconds**: Standard Unix time does not account for leap seconds — it assumes every day is exactly 86,400 seconds. For most applications this is irrelevant, but for GPS systems, financial trading timestamps, and scientific instruments, this distinction matters. The IERS maintains the leap second table. **Discord Timestamps: A Modern Use Case** Discord popularized a specific Unix timestamp syntax for chat messages. Wrapping a timestamp in angle brackets renders it in every user's local timezone automatically. Use this converter to get the Unix timestamp for any date, then paste it into one of these formats: | Discord code | Renders as | |---|---| | `<t:1706745600:d>` | 02/01/2024 | | `<t:1706745600:D>` | February 1, 2024 | | `<t:1706745600:t>` | 12:00 AM | | `<t:1706745600:T>` | 12:00:00 AM | | `<t:1706745600:f>` | February 1, 2024 12:00 AM | | `<t:1706745600:F>` | Thursday, February 1, 2024 12:00 AM | | `<t:1706745600:R>` | 4 months ago (relative) | This is the recommended approach for Discord server announcements, event reminders, and countdown timers — the timestamp displays correctly for members in every timezone worldwide without any manual timezone conversion. **Relative Time Calculations** The Discord `:R` format hints at a broader concept: relative timestamps — displaying "3 hours ago" or "in 2 days" instead of an absolute date. Reddit, GitHub, Stack Overflow, and most modern web apps use this pattern. Here's the standard JavaScript implementation: ```js const now = Math.floor(Date.now() / 1000); // current Unix timestamp (seconds) const posted = 1706745600; // stored timestamp const diff = now - posted; // seconds elapsed if (diff < 60) return `${diff} seconds ago`; if (diff < 3600) return `${Math.floor(diff / 60)} minutes ago`; if (diff < 86400) return `${Math.floor(diff / 3600)} hours ago`; return `${Math.floor(diff / 86400)} days ago`; ``` Use this converter to verify "posted_at" timestamps from your database — helpful when debugging why a post shows "1 hour ago" when it should show "2 days ago." **Pro Tips for Backend Developers** **Use this converter for log analysis**: When debugging a production incident in AWS CloudWatch or Datadog, you often see log entries with epoch timestamps. Copy the timestamp here, get the human-readable time, and you can immediately tell whether a spike happened at 2 AM (low-traffic, likely cron job) or 2 PM (peak traffic, likely user-facing bug). **Verify cron job scheduling**: Cron expressions and scheduled Lambda functions fire at UTC times. If you schedule a job for `0 14 * * *` (2 PM UTC), that's 9 AM Eastern or 6 AM Pacific. Use this converter to verify your scheduled tasks fire at the intended wall-clock time for your users. **Bookmark-worthy shortcut**: In most Unix terminals, `date -d @1706745600` converts a timestamp to local time on Linux. On macOS, use `date -r 1706745600`. For UTC output on Linux: `date -u -d @1706745600`. **Use timestamps for cache-busting**: API responses often include an `ETag` or `Last-Modified` timestamp. If you're implementing cache invalidation, comparing Unix timestamps (integer subtraction) is faster and more reliable than parsing date strings.