Unix Epoch Converter
Convert Unix timestamps to human-readable dates instantly — and convert dates back to Unix timestamps. Shows both UTC and local timezone. Detects seconds vs milliseconds automatically. Includes a Reset to Now button for the current timestamp.
Convert Unix timestamps to human-readable dates instantly — and convert dates back to Unix timestamps. Shows both UTC and local timezone. Detects seconds vs milliseconds automatically. Includes a Reset to Now button for the current timestamp.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
Unix epoch time — also called Unix time, POSIX time, or simply a timestamp — is the number of seconds that have elapsed since 00:00:00 UTC on Thursday, 1 January 1970, not counting leap seconds. This specific moment is called the Unix Epoch. A Unix timestamp is a single integer that uniquely identifies any moment in time relative to the epoch, regardless of timezone, locale, calendar system, or daylight saving time. The timestamp 1716652800 represents exactly one specific instant in time — Mon 25 May 2026 12:00:00 UTC — the same for every system in the world.
Unix time is used in computers and software instead of human-readable date strings for three reasons. First, it is unambiguous: 25/05/2026 can mean May 25 or 25 May depending on locale, and 12:00 PM on May 25 in New York is a different moment from 12:00 PM on May 25 in Mumbai. A Unix timestamp has no such ambiguity — it means exactly one moment. Second, it is computationally efficient: comparing two timestamps or calculating the duration between two events is simple integer arithmetic (subtract two numbers) rather than date parsing and timezone conversion. Third, it is universally supported: every major programming language, database, and operating system natively understands Unix timestamps.
Some systems use millisecond-precision timestamps — the number of milliseconds since the Unix Epoch — for finer granularity. A millisecond timestamp is approximately 1000 times larger than a second timestamp for the same moment: 1716652800000 milliseconds equals 1716652800 seconds. JavaScript's Date.now(), Java's System.currentTimeMillis(), and most event logging systems use milliseconds. Linux system calls, Unix database default timestamp columns, and most REST API date fields use seconds. This distinction — seconds vs milliseconds — is the most common source of confusion and calculation errors when working with timestamps across different systems.
Read the Full GuideThis tool converts Unix timestamps to human-readable dates in both directions. Enter a Unix timestamp (in either seconds or milliseconds — the tool auto-detects which by checking whether the value is likely a seconds-precision or milliseconds-precision timestamp based on its magnitude) and it displays the corresponding date and time in two formats: UTC timeline showing the date and time in Coordinated Universal Time, and Local timeline showing the date and time in your browser's local timezone. Both are displayed side by side with copy buttons. For the current timestamp, the Reset to Now button populates the input field with the current Unix timestamp in seconds at the moment you click it, which is useful when you need to know the current epoch time for use in an API call, a database query, a cURL command, or any other context where you need the current time as a number rather than a formatted string. The conversion also works in reverse — you can type or paste a human-readable date string into the input and the tool converts it to the corresponding Unix timestamp. This is useful when you need to construct a timestamp for a specific historical or future date for use in an API request, a database WHERE clause, or a scheduled job. The tool displays the timestamp in both seconds and milliseconds precision so you can copy whichever format the target system expects.
1. Enter a Unix timestamp into the Unix Epoch Timestamp input field — paste any numeric timestamp from a database record, API response, log file, or any other source. The tool accepts both seconds-precision timestamps (10 digits, like 1716652800) and milliseconds-precision timestamps (13 digits, like 1716652800000) and auto-detects which format you have entered based on the magnitude of the value. If you are not sure whether your timestamp is in seconds or milliseconds, paste it in and check whether the displayed date looks reasonable.
2. Click Convert Timestamp — the tool immediately converts the input timestamp to a human-readable date and time in two formats shown side by side: UTC Timeline showing the date and time in Coordinated Universal Time (the timezone-neutral reference), and Local Timeline showing the date and time in your browser's local timezone and locale format. Use the UTC version for system-level comparisons and the Local version to understand when the event happened in your local time.
3. Click Reset to Now to populate the input with the current Unix timestamp in seconds at the exact moment you click the button — useful when you need the current time as a Unix timestamp for pasting into an API request, a database query, or a curl command without needing to run date +%s in a terminal.
4. Copy either timestamp display using the Copy button next to the UTC or Local timeline — the formatted date string is copied to your clipboard ready to paste into documentation, a bug report, a log annotation, or a message to a colleague who needs to know when an event occurred.
5. For the reverse conversion (date to timestamp): type or paste a human-readable date string into the input field. The tool recognizes common date formats and converts to the corresponding Unix timestamp in both seconds and milliseconds so you can use whichever precision your target system expects.
The scenario where I reach for an epoch converter most often is reading database records or application logs. A database row with created_at: 1716652800 tells me nothing until I convert it to a readable date. An API response with expires_at: 1716739200 — is that a token that expired 3 days ago, or one that expires tomorrow? A log line with ts=1716652651245 — is that in seconds (year 56424, clearly wrong) or milliseconds (Mon 25 May 2026 11:57:31 UTC, correct)? Converting timestamps is a constant part of debugging APIs, databases, and distributed systems, and doing the mental math is error-prone. This tool gives you the answer in under a second. The seconds vs milliseconds distinction is where most timestamp bugs originate. JavaScript's Date.now() returns milliseconds. Unix time() returns seconds. If code that expects seconds receives a milliseconds value and stores it in a database integer field, the stored timestamp represents a date roughly 50 years in the future — a number like 1716652800000 seconds is year 56424. If the reverse happens — milliseconds expected but seconds provided — the timestamp represents a date in January 1970, which immediately fails any "is this timestamp recent" validation. Seeing the converted date immediately tells you whether you have the right precision. The Reset to Now button is useful for one specific workflow: constructing API requests that include a timestamp parameter for "now." Many APIs accept Unix timestamps for filtering (created_after, updated_before) or for specifying event times. Rather than manually calculating the current timestamp — which requires either mental math or running date +%s in a terminal — clicking Reset to Now gives you the current epoch time in seconds that you can paste directly into a cURL request, a Postman parameter, or an API call in your code.
Auto-detects seconds vs milliseconds — identifies whether your input is a seconds-precision (10-digit) or milliseconds-precision (13-digit) timestamp automatically so you do not need to know which format your timestamp is in before converting
Shows both UTC and local timezone — displays the converted date in both UTC and your browser's local timezone side by side so you can see both the system time and your local time without separate conversions
Reset to Now button — instantly populates the input with the current Unix timestamp in seconds for use in API requests database queries and terminal commands
Bidirectional conversion — converts timestamps to dates AND dates to timestamps covering both directions of the most common timestamp operations
Copy buttons for both timelines — the UTC and local date strings can each be copied individually with a single click
100% browser-based — your timestamps never leave your machine making it safe to convert timestamps that contain encoded time information about sensitive operations
Instant conversion — results appear immediately with no server round-trip using the browser's native Date API
Works for historical and future dates — converts timestamps from any point in Unix time history and into the future for date planning and API parameter construction
Converting database timestamp fields to readable dates when debugging API responses or data migrations
Checking whether an API token or session is expired by converting its expires_at timestamp to a readable date
Debugging log files that use Unix timestamps to understand when specific events occurred
Constructing API request parameters that require Unix timestamps for date filtering (created_after updated_before etc.)
Converting timestamps in distributed system traces to understand the sequence and timing of events across services
Checking whether a Unix timestamp in a codebase represents seconds or milliseconds by converting and verifying the result looks reasonable
Getting the current Unix timestamp to use in curl commands API testing or database queries
Converting historical or future dates to Unix timestamps for use in scheduled job parameters or API calls
Example Input
1716652800
Example Output
Input: 1716652800 (detected: seconds precision) UTC Timeline: Mon, 25 May 2026 12:00:00 GMT Local Timeline: 25/05/2026, 17:30:00 (IST, UTC+5:30) Also available: Milliseconds: 1716652800000 ISO 8601: 2026-05-25T12:00:00.000Z RFC 2822: Mon, 25 May 2026 12:00:00 +0000
Invalid Format — Non-Numeric Input: The tool requires a numeric Unix timestamp. If you paste text like '2026-05-25' or a formatted date string into the timestamp field, the tool will attempt to parse it as a date-to-timestamp conversion. If the input is neither a valid numeric timestamp nor a recognizable date format, the tool will report an invalid format error. Ensure your input is either a pure integer (seconds or milliseconds) or a standard date string.
Precision Mismatch — Timestamp Appears as Wrong Year: If a milliseconds timestamp is treated as seconds (or vice versa), the converted date will be wildly wrong — a milliseconds value like 1716652800000 treated as seconds gives a date in approximately the year 56,424, and a seconds value like 1716652800 treated as milliseconds gives a date in January 1970. If the converted date looks unreasonable, check whether the tool auto-detected the correct precision. A 10-digit number is seconds, a 13-digit number is milliseconds. If your timestamp has a different number of digits, verify the precision with the system that generated it.
Empty Input: Clicking Convert Timestamp with an empty input field will prompt you to enter a value. Either type a timestamp directly, paste one from a log or database, or click Reset to Now to populate the field with the current timestamp.
Timestamp Before the Unix Epoch: Unix timestamps are defined as seconds since January 1 1970 00:00:00 UTC. Negative timestamps represent dates before the epoch — for example -86400 represents December 31 1969 00:00:00 UTC. Most programming languages and databases support negative Unix timestamps for pre-1970 dates. If you need to convert a historical date before 1970, enter a negative timestamp value. The tool handles negative timestamps correctly.
Future Timestamp Overflow (Y2K38 Issue): 32-bit signed integers can represent Unix timestamps up to 2,147,483,647 seconds, which corresponds to January 19 2038 03:14:07 UTC — this is the Y2K38 problem. Systems that store Unix timestamps in 32-bit integers will overflow and roll back to a negative value after this moment. Modern systems use 64-bit integers which can represent timestamps billions of years into the future. If you are working with a legacy system and see timestamps that wrap around to 1970, this may be a 32-bit overflow issue.
Assuming a timestamp is in seconds when it is in milliseconds (or vice versa)
Fix: The fastest way to tell whether a Unix timestamp is in seconds or milliseconds is by counting the digits. A seconds-precision timestamp in 2026 has 10 digits (1716652800). A milliseconds-precision timestamp in 2026 has 13 digits (1716652800000). A microseconds timestamp has 16 digits. If you see a timestamp that is much larger than you expect, multiply or divide by 1000 to switch between seconds and milliseconds. Always check the documentation of the system that generated the timestamp — JavaScript Date.now() and most event streaming systems use milliseconds, Unix system calls and most database default timestamp columns use seconds.
Interpreting a UTC timestamp as local time without converting
Fix: Unix timestamps are defined in UTC — they represent a specific moment in absolute time with no timezone information embedded. When you display or store a timestamp as a human-readable date, you must explicitly choose a timezone. '1716652800 = 12:00 PM' is incomplete — it is 12:00 PM UTC, but 5:30 PM IST, 8:00 AM EDT, and 2:00 AM PDT simultaneously. A meeting scheduled for epoch 1716652800 starts at a different clock time depending on where you are. When communicating timestamps to humans, always specify the timezone explicitly, or use ISO 8601 format with the offset: 2026-05-25T12:00:00+00:00 for UTC or 2026-05-25T17:30:00+05:30 for IST.
Storing timestamps as formatted date strings in databases instead of Unix timestamps
Fix: Storing timestamps as strings like '25 May 2026 12:00 PM IST' creates several problems: string comparison is not time comparison (string sorting does not sort by time correctly), timezone information may be lost or inconsistent across records, and parsing varies by locale and format. Always store timestamps as Unix timestamps (integers) in databases — they sort correctly, compare correctly, allow efficient range queries, and are timezone-neutral. When you need to display a timestamp to a user, convert from the stored Unix timestamp to the appropriate local time at display time, not at storage time.
Not accounting for DST when displaying timestamps in local time
Fix: When you convert a Unix timestamp to local time, the result depends on whether DST is in effect at that moment in the target timezone — not just on the current DST status. A timestamp from December (when New York is in EST, UTC-5) displayed as New York local time should be UTC-5, while a timestamp from July (when New York is in EDT, UTC-4) should be UTC-4. If you hard-code a UTC offset rather than using a proper timezone conversion library, you will display the wrong local time for timestamps in the other DST period. Always use a timezone-aware date library (Luxon, date-fns-tz in JavaScript, pytz or zoneinfo in Python) that accounts for DST transitions rather than adding a fixed offset.
Using timestamp arithmetic without accounting for timezone when comparing times
Fix: Unix timestamp arithmetic (subtraction, addition) is always correct because timestamps are UTC integers — the duration between timestamps 1716652800 and 1716739200 is exactly 86400 seconds (one day) regardless of timezone. But when you construct a timestamp from a date and time for a specific timezone — 'I want the timestamp for 9 AM Monday in New York' — you must account for the UTC offset and whether DST applies at that moment. Adding 9 hours to midnight UTC does not give you 9 AM New York time. Use timezone-aware date construction: new Date('2026-05-25T09:00:00-04:00').getTime()/1000 in JavaScript gives the correct UTC Unix timestamp for 9 AM EDT (UTC-4).
Cron Expressions
Quick reference guide for UNIX Cron patterns: minute, hour, day, month, day-of-week, special strings, and automation schedules.
Bash
Quick reference for Bash commands: file operations, piping, process control, environment variables, conditions, and shell scripting loops.
Linux Commands
Interactive handbook for terminal navigation, file administration, permissions, process handling, and basic networking utilities.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
What is a Unix timestamp?
A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on January 1 1970 — called the Unix Epoch. It is a single integer that uniquely identifies any moment in time regardless of timezone, locale, or daylight saving time. The timestamp 1716652800 represents exactly one specific instant: Mon 25 May 2026 12:00:00 UTC. The same timestamp means the same moment for every system in the world, which is why it is the standard format for storing and exchanging date and time values in software.
Does it support all timezones?
Yes. The tool displays the converted timestamp in two formats: UTC (Coordinated Universal Time, timezone-neutral) and your browser's local timezone detected automatically from your system settings. The local timezone display uses your browser's locale and timezone offset, so it reflects your actual local time including DST adjustments if your region observes daylight saving time. If you need to see a timestamp in a third timezone that is neither UTC nor your local timezone, convert the UTC time manually by adding or subtracting the target timezone's UTC offset.
Is it safe for sensitive timestamps?
Yes. All timestamp conversion runs entirely in your browser using the native JavaScript Date API. Your timestamps — which may encode information about user activity, financial transactions, security events, or operational schedules — never leave your machine and are never transmitted to any server. This matters for systems where the timing of certain operations is considered sensitive operational information.
What is the difference between seconds and milliseconds timestamps?
Both represent the same concept — time elapsed since the Unix Epoch — but at different granularities. A seconds timestamp in 2026 is a 10-digit number around 1,716,652,800. A milliseconds timestamp in 2026 is a 13-digit number around 1,716,652,800,000. To convert between them, multiply seconds by 1000 to get milliseconds, or divide milliseconds by 1000 to get seconds. JavaScript's Date.now() returns milliseconds. Unix system calls like time() return seconds. Most database timestamp columns store seconds. Most event logging and monitoring systems use milliseconds for higher precision.
How do I get the current Unix timestamp in code?
In JavaScript (browser or Node.js): Math.floor(Date.now() / 1000) for seconds or Date.now() for milliseconds. In Python: import time then int(time.time()) for seconds or int(time.time() * 1000) for milliseconds. In Go: time.Now().Unix() for seconds or time.Now().UnixMilli() for milliseconds. In Java: System.currentTimeMillis() / 1000 for seconds or System.currentTimeMillis() for milliseconds. In bash/shell: date +%s for seconds. In SQL (PostgreSQL): EXTRACT(EPOCH FROM NOW())::BIGINT for seconds. In SQL (MySQL): UNIX_TIMESTAMP() for seconds.
What is the Y2K38 problem?
The Y2K38 problem (also called the Unix millennium bug or Year 2038 problem) is that 32-bit signed integers can only represent Unix timestamps up to 2,147,483,647 — which corresponds to January 19 2038 03:14:07 UTC. After that moment, a 32-bit timestamp overflows to a large negative value, making the date appear to reset to December 13 1901. Systems that store timestamps in 32-bit integers — including some embedded systems, legacy databases, and older 32-bit operating systems — are affected. Modern systems use 64-bit integers which can represent timestamps billions of years into the future, so new software is not affected. If you are working on a legacy system, migrating timestamp storage to 64-bit integers before 2038 is essential.
How do I convert a specific date to a Unix timestamp?
In JavaScript: new Date('2026-05-25T12:00:00Z').getTime() / 1000 for a UTC date (divide by 1000 to get seconds from milliseconds). For a specific timezone: new Date('2026-05-25T09:00:00-05:00').getTime() / 1000 where -05:00 is the UTC offset. In Python: from datetime import datetime, timezone then int(datetime(2026, 5, 25, 12, 0, 0, tzinfo=timezone.utc).timestamp()). In bash: date -d '2026-05-25 12:00:00 UTC' +%s on Linux. Always specify the timezone explicitly when constructing a timestamp from a local date to avoid your system's local timezone being assumed incorrectly.
Why do some APIs use negative Unix timestamps?
Negative Unix timestamps represent dates before January 1 1970 00:00:00 UTC. The timestamp -86400 represents December 31 1969 00:00:00 UTC (one day before the epoch). Negative timestamps are completely valid in the Unix time system and are supported by all 64-bit timestamp implementations. Some APIs that work with historical data — financial records, historical events, birth dates before 1970 — use negative timestamps for pre-epoch dates. If you see a small negative number as a timestamp, it likely represents a date in late 1969 or earlier. If you see a very large negative number, it may indicate a 32-bit overflow where a 2038+ date has wrapped around.
Recent Activity
No recent activity