Free Unix timestamp converter. Paste any epoch time and get the date instantly in your browser — seconds, milliseconds, FILETIME, hex, batch, any timezone.
A Unix timestamp is a single integer that counts the seconds elapsed since January 1, 1970 at 00:00:00 UTC — the moment known as the Unix epoch. It is the most widely used time representation in computing, appearing in database columns, API payloads, JWT expiry claims, server logs, and file metadata. This Unix timestamp converter turns any epoch value into a human–readable date in the timezone you choose, and turns any date back into a timestamp, instantly and entirely in your browser. Nothing you paste is uploaded anywhere.
Unlike most epoch converters, this tool is not limited to plain Unix seconds. It auto–detects and converts Unix seconds, Unix milliseconds, Windows FILETIME in decimal and hexadecimal, Active Directory / LDAP timestamps, WebKit & Chrome timestamps, and Cocoa / Mac Absolute Time — and it converts a single value or a whole pasted column of them in batch mode. A live clock at the top shows the current Unix timestamp, ticking every second, so you always have “now” on hand.
The tool has two directions and two modes. Getting an answer takes one paste.
1735689600 into the timestamp field. The tool detects the format automatically — a 10–digit number is read as seconds, 13 digits as milliseconds, an 18–digit number as FILETIME, and anything beginning 0x as hexadecimal FILETIME. Override the detection with the format selector if you know better.Unix time — also called POSIX time or epoch time — counts forward one integer per second from the epoch, with dates before 1970 expressed as negative numbers. That is the whole specification, and its simplicity is why it won. Any point in time becomes a single comparable integer, so sorting records chronologically is an integer sort and the gap between two events is one subtraction. All the messy calendar detail — months of 28, 29, 30 or 31 days, leap years, daylight saving transitions — is pushed to the conversion layer at the edges of your system and kept out of the arithmetic.
The choice of 1970 was not arbitrary. Unix was being built at Bell Labs by Dennis Ritchie, Ken Thompson and colleagues in the late 1960s, and they needed an origin recent enough not to waste range on distant history but early enough to cover the files the system would actually see; on the 32–bit hardware of the day, seconds–since–1970 fit comfortably in one machine word. As Unix and its descendants — Linux, the BSDs, macOS — spread, the convention travelled with them, and today it is the default in MySQL and PostgreSQL, in JavaScript and Python, and in essentially every web API that timestamps anything.
Not everything that looks like an epoch value is Unix seconds. Microsoft, Apple and Chrome each count from a different origin at a different resolution, which is why an unrecognised 18–digit number in a forensic export can look like nonsense. The table below is the field guide.
| Format | Epoch | Unit | Typical length | Example |
|---|---|---|---|---|
| Unix seconds | 1970–01–01 UTC | Seconds | 10 digits | 1735689600 |
| Unix milliseconds | 1970–01–01 UTC | Milliseconds | 13 digits | 1735689600000 |
| Windows FILETIME | 1601–01–01 UTC | 100–nanosecond ticks | 18 digits | 133696152000000000 |
| FILETIME (hex) | 1601–01–01 UTC | 100–nanosecond ticks | 16 hex chars | 0x19db1ded53e8000 |
| Active Directory / LDAP | 1601–01–01 UTC | 100–nanosecond ticks | 18 digits | same as FILETIME |
| WebKit / Chrome | 1601–01–01 UTC | Microseconds | 17 digits | 13369615200000000 |
| Cocoa / Mac Absolute Time | 2001–01–01 UTC | Seconds | 9 digits | 757382400 |
Two constants explain most of the confusion. The gap between the Windows epoch of 1601 and the Unix epoch of 1970 is 11644473600 seconds, which expressed in 100–nanosecond ticks is the famous 116444736000000000 — the number you subtract from a FILETIME before dividing by 10,000,000 to get Unix seconds. The gap between the Cocoa epoch of 2001 and the Unix epoch is 978307200 seconds; add it to a Cocoa value to get Unix time. The tool applies both automatically, using arbitrary–precision integers so that 18–digit FILETIME values do not lose accuracy the way ordinary floating–point arithmetic would.
| Timestamp | Meaning |
|---|---|
0 | 1970–01–01 00:00:00 UTC — the Unix epoch itself. Often a sign of an uninitialised field rather than a real date. |
1000000000 | 2001–09–09 01:46:40 UTC — the “billennium” second. |
1234567890 | 2009–02–13 23:31:30 UTC — a favourite test fixture. |
1735689600 | 2025–01–01 00:00:00 UTC. |
2147483647 | 2038–01–19 03:14:07 UTC — the maximum signed 32–bit value, where the Year 2038 problem bites. |
-1 | 1969–12–31 23:59:59 UTC. Frequently an error sentinel, not a date. |
116444736000000000 | The FILETIME value of the Unix epoch — the conversion constant between the two systems. |
Every mainstream language exposes epoch time, but the default unit differs, and that difference is the single most common source of timestamp bugs. JavaScript and Java return milliseconds; PHP, Python, Go and the shell return seconds.
| Language | Current timestamp | Unit |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | Date.now() is milliseconds |
| Python | int(time.time()) | Seconds (float with sub–second precision) |
| PHP | time() | Seconds |
| Java | System.currentTimeMillis() | Milliseconds |
| Go | time.Now().Unix() | Seconds |
| C# / .NET | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | Seconds |
| Bash / Linux | date +%s | Seconds |
| PowerShell | [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() | Seconds |
| MySQL | SELECT UNIX_TIMESTAMP(); | Seconds |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM NOW()); | Seconds |
| SQLite | SELECT strftime('%s','now'); | Seconds |
Going the other way, date -d @1735689600 on Linux, datetime.utcfromtimestamp(1735689600) in Python, and SELECT FROM_UNIXTIME(1735689600) in MySQL all render a timestamp as a date. Be explicit about the timezone in every one of those calls: most of them default to the machine’s local zone, which is a reliable way to produce results that differ between your laptop and your production server.
Mixing the two units is the classic epoch mistake. Feed a seconds value into a function expecting milliseconds and your date lands in January 1970; feed milliseconds into a seconds parser and you get a date tens of thousands of years in the future.
new Date(1735689600) in JavaScript does not give you January 2025 — it gives you a moment 20 days after the epoch, because the constructor expects milliseconds. The correct call is new Date(1735689600 * 1000). Converting the other way, use Math.floor(Date.now() / 1000) rather than plain division, so you send an integer to a backend that expects one.
A quick heuristic when you are staring at an unknown value: 10 digits is seconds, 13 is milliseconds, 16 is microseconds, 19 is nanoseconds, 17–18 digits starting with 13 is almost certainly a Windows or Chrome timestamp. Paste it into the converter above and check whether the resulting date is plausible — a date in 1970, 1601 or the year 56000 tells you the unit guess was wrong.
A Unix timestamp is always UTC. It carries no offset, no zone name, and no daylight–saving flag, because it does not need them: it identifies an instant, not a wall–clock reading. That property removes an entire category of bugs. If a meeting is scheduled at timestamp 1735689600, systems in New York, London and Tokyo all store the identical integer and each renders it in local time only at the moment of display.
That single property is why epoch time turns up everywhere it does: sorting a social feed chronologically, correlating log lines across servers in different regions, enforcing API rate limits over a rolling window, deciding which files a backup has not yet copied, expiring a session or a JWT, and recording created/modified times in a database are all just integer comparisons once time is expressed this way.
The best practice that follows is short: store in UTC, display in local. Keep timestamps as epoch integers or UTC–anchored types in the database, do all arithmetic in that space, and convert to the user’s zone in the presentation layer alone. Never persist a local wall–clock time without an accompanying offset or zone identifier — once daylight saving shifts, the value becomes genuinely ambiguous, and during a DST fall–back hour a local time can legitimately refer to two different instants. This converter models that pattern directly: one instant, rendered simultaneously as UTC, ISO 8601, and the timezone of your choosing.
A signed 32–bit integer maxes out at 2,147,483,647. As a Unix timestamp that is 03:14:07 UTC on January 19, 2038. One second later, a 32–bit signed counter overflows to its most negative value and the date reads as December 13, 1901. This is the Year 2038 problem, and it is the direct descendant of Y2K.
Modern 64–bit platforms are unaffected: a signed 64–bit second counter covers roughly 292 billion years in each direction, which comfortably outlasts any software you will write. The risk lives in the places that did not get recompiled — embedded controllers, industrial and building–automation devices, legacy binaries with 32–bit time_t, database columns typed INT instead of BIGINT, and file formats that fixed the field width. The practical mitigation is unexciting: use 64–bit time types, declare epoch columns as BIGINT, and test any long–lived system with dates past 2038 rather than assuming it copes. Contract expiry dates, mortgage schedules and certificate lifetimes already cross the boundary today.
Unix time asserts that every day contains exactly 86,400 seconds. Reality disagrees occasionally: leap seconds are inserted to keep atomic time aligned with the Earth’s rotation, and Unix time simply does not represent them — depending on the platform the clock repeats a second or smears it across a window. For almost all applications this is invisible; for high–precision timing or systems that must reconcile with TAI, it needs explicit handling.
Negative timestamps for pre–1970 dates are mathematically fine but handled badly by plenty of libraries and drivers, so test historical dates rather than trusting them. Watch the precision ceiling too: JavaScript numbers stop representing integers exactly above 253, so nanosecond timestamps and large FILETIME values need BigInt. And treat 0 with suspicion — in production data an epoch–zero timestamp is far more often an uninitialised field than a genuine record from 1970.
Incident responders and Windows administrators meet epoch time in a different dialect. Active Directory stores lastLogonTimestamp, pwdLastSet and accountExpires as 18–digit FILETIME integers; NTFS records file MACB times the same way; and Chrome’s history and cookie databases use microseconds since 1601. Those values will not survive a plain epoch converter, which is why this one accepts them directly — decimal or hex — and shows the same instant in every format side by side.
Two special values are worth memorising: a FILETIME of 0 in Active Directory means “never”, and 9223372036854775807 in accountExpires also means “never” rather than a date in the year 30828. For bulk triage, paste an entire exported column into batch mode instead of converting rows one at a time.
created_at_ms beats created_at.INT column is a 2038 bug with a delivery date.timestamptz normalises to UTC internally.01/02/2025 mean different days on different continents.Epoch integers are not the only option. ISO 8601 gives a human–readable string that carries its own offset, and RFC 3339 is the tightened subset of ISO 8601 that internet protocols and JSON APIs actually use — 2025-01-01T00:00:00Z. Both are excellent on the wire and in logs a person will read; both cost more bytes and more parsing than an integer. Some scientific and financial systems go further and use TAI to avoid leap–second ambiguity entirely. None of these displaces Unix time, which after fifty years of ecosystem support remains the default anywhere time has to be compact, comparable and unambiguous. The converter above emits ISO 8601 alongside every other format, so you can move between the two conventions without thinking about it.
Once you have a timestamp, the neighbouring tools finish the job. Use the Time Duration Calculator to work out the exact interval between two moments in days, hours, minutes and seconds. Use the World Clock to see one instant across multiple regions at once when you are coordinating a change window. Use the Windows FILETIME Converter when you are working purely in Microsoft timestamp formats, and the Cron Expression Builder when the next step is scheduling something to run at a particular time. The full set is in developer tools.
A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, ignoring leap seconds. It is also called Unix time, POSIX time or epoch time. Because it is a single integer anchored to UTC, it identifies an exact instant with no timezone ambiguity, which is why databases, APIs and log files use it so widely.
Paste the value into the converter above and pick a timezone — the formatted date, ISO 8601 string, UTC time and relative “time ago” all appear immediately. In code, use new Date(ts * 1000) in JavaScript, datetime.utcfromtimestamp(ts) in Python, date -d @ts on Linux, or FROM_UNIXTIME(ts) in MySQL.
The standard Unix timestamp is in seconds and currently has 10 digits. JavaScript’s Date.now() and Java’s System.currentTimeMillis() return milliseconds, which is 13 digits. Multiply by 1,000 to go from seconds to milliseconds and divide (with Math.floor) to go back. This converter detects the unit from the digit count and also lets you set it manually.
UTC, always. A Unix timestamp carries no timezone information because it names an instant rather than a wall–clock reading. Timezone only enters when you render it for a human, which is why the converter above lets you switch zones and see the same timestamp displayed differently without the underlying number changing.
Divide the FILETIME by 10,000,000 to convert 100–nanosecond ticks to seconds, then subtract 11644473600 — the number of seconds between the 1601 Windows epoch and the 1970 Unix epoch. Expressed in FILETIME units that constant is 116444736000000000. Paste a decimal or 0x hexadecimal FILETIME into the tool and it applies the conversion for you using exact big–integer arithmetic.
It is the Windows FILETIME representation of the Unix epoch — that is, 1970–01–01 00:00:00 UTC expressed as 100–nanosecond intervals since 1601–01–01. It appears constantly in conversion code and in Windows internals documentation as the offset between the two epochs. The hexadecimal form of the same value is 0x19db1ded53e8000.
At 03:14:07 UTC on January 19, 2038, a signed 32–bit Unix timestamp reaches its maximum of 2,147,483,647 and overflows to a negative number, which systems then read as December 13, 1901. Any platform using 64–bit time is unaffected. The exposure is in legacy and embedded code, 32–bit time_t, and database columns declared as INT instead of BIGINT.
Yes. Negative values represent dates before January 1, 1970 — -86400 is December 31, 1969. The arithmetic is well defined, but support varies across languages, drivers and databases, so always test historical dates explicitly rather than assuming they round–trip correctly.
Yes. Switch to batch mode and paste one timestamp per line. The tool returns a table with the original input, the UTC date, the Unix value and the FILETIME equivalent for each row, which is the fastest way to read a log export or a column pulled from a forensic image.
No. All parsing and conversion runs in your browser using JavaScript. Timestamps you paste — including values taken from logs or forensic artifacts — are never transmitted to a server, and the tool is free with no signup.
A Unix timestamp (also called Epoch time or POSIX time) represents a point in time as the number of seconds elapsed since January 1, 1970, 00:00:00 UTC — known as the Unix Epoch. This integer representation is the standard time format used by operating systems, databases, APIs, log files, and programming languages because it is timezone-independent, unambiguous, and easy to perform arithmetic on.
Unix timestamps appear everywhere in technical systems: API responses, database records, JWT tokens, file metadata, log entries, and system calls. Converting between human-readable dates and Unix timestamps is a daily task for developers, system administrators, and security analysts.
| Format | Example | Precision | Range |
|---|---|---|---|
| Unix seconds | 1706400000 | Seconds | 1970-01-01 to 2038-01-19 (32-bit) |
| Unix milliseconds | 1706400000000 | Milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() |
| Unix microseconds | 1706400000000000 | Microseconds | Python time.time_ns(), database precision |
| Unix nanoseconds | 1706400000000000000 | Nanoseconds | Go time.Now().UnixNano() |
| ISO 8601 | 2024-01-28T00:00:00Z | Varies | Human-readable standard |
| RFC 2822 | Sun, 28 Jan 2024 00:00:00 +0000 | Seconds | Email headers |
32-bit signed integers can store Unix timestamps up to 2,147,483,647 — which corresponds to January 19, 2038, 03:14:07 UTC. After this moment, 32-bit systems will overflow, potentially causing failures similar to Y2K. Most modern systems use 64-bit timestamps, which extend to approximately 292 billion years.
Unix timestamp (epoch time) is seconds elapsed since January 1, 1970, 00:00:00 UTC (the "Unix epoch"). Example: 1609459200 = January 1, 2021, 00:00:00 UTC. Used because: timezone-independent (always UTC), easy arithmetic (1735689600 - 1609459200 = seconds between dates), compact storage (32-bit integer vs date string), universal standard across programming languages, sortable (higher number = later time). Negative values represent dates before 1970. 2038 problem: 32-bit timestamps overflow on January 19, 2038 (2,147,483,647 seconds) - solved with 64-bit integers. This tool converts between Unix time and readable formats instantly.
Unix timestamps use seconds by default (10 digits: 1609459200). JavaScript uses milliseconds (13 digits: 1609459200000) - multiply by 1000 to convert. Identify by length: 10 digits = seconds, 13 digits = milliseconds, 16 digits = microseconds (rare). Conversion: seconds × 1000 = milliseconds, milliseconds ÷ 1000 = seconds. Why milliseconds: higher precision for timing events, JavaScript Date() expects milliseconds, performance measurement needs sub-second accuracy. Use seconds for: dates, events, logs. Use milliseconds for: timestamps in code, performance metrics, precise event timing. This tool detects format automatically and converts between both.
Unix timestamps are always UTC - timezone-agnostic. Display conversion adds timezone offset. Example: 1609459200 displays as "Jan 1, 2021 00:00 UTC" or "Dec 31, 2020 19:00 EST" (UTC-5). Storage best practice: always store UTC timestamps, convert to local timezone only for display. Avoid storing local time (ambiguous during DST transitions, moving users between zones). Common mistakes: comparing timestamps from different zones, forgetting DST shifts, using local time in databases. Solutions: use UTC everywhere in backend, convert to user timezone in frontend only, ISO 8601 format for APIs (2021-01-01T00:00:00Z). This tool shows timestamps in multiple timezones simultaneously.
JavaScript: new Date(1609459200 * 1000) for seconds, Date.now() gets current milliseconds. Python: datetime.fromtimestamp(1609459200), time.time() for current. PHP: date("Y-m-d H:i:s", 1609459200), time() for current. MySQL: FROM_UNIXTIME(1609459200), UNIX_TIMESTAMP() for current. PostgreSQL: to_timestamp(1609459200), extract(epoch from now()). Java: new Date(1609459200L * 1000), System.currentTimeMillis(). Go: time.Unix(1609459200, 0), time.Now().Unix(). Remember: JavaScript/Java use milliseconds, most others use seconds. This tool generates code snippets for common languages.
32-bit signed integers max at 2,147,483,647 (January 19, 2038, 03:14:07 UTC) then overflow to negative (wraps to December 13, 1901). Affects: legacy 32-bit systems, embedded devices, old databases, C/C++ time_t on 32-bit platforms. Solutions: use 64-bit integers (supports year 292 billion+), update system libraries, upgrade to 64-bit OS, use unsigned 32-bit (extends to 2106). Modern systems: 64-bit by default (Python, JavaScript, Java long, PostgreSQL bigint). Check your system: if storing timestamps as 32-bit int, migrate to 64-bit now. This tool uses 64-bit timestamps supporting dates far beyond 2038.
Subtract timestamps to get seconds difference: 1735689600 - 1609459200 = 126230400 seconds. Convert to units: ÷ 60 = minutes, ÷ 3600 = hours, ÷ 86400 = days, ÷ 31536000 ≈ years. Example: 126230400 ÷ 86400 = 1,461 days = 4 years. For elapsed time: current_timestamp - event_timestamp. For future events: event_timestamp - current_timestamp. Add duration: timestamp + (days × 86400). Subtract duration: timestamp - (hours × 3600). Advantages: no timezone confusion, no DST issues, simple arithmetic. Disadvantages: doesn't account for months (varying lengths) or leap seconds. This tool calculates differences and shows results in multiple time units.
Mixing seconds and milliseconds - most common error. Use 10 digits (seconds) vs 13 (milliseconds). Timezone confusion - storing local time instead of UTC. Solution: always UTC. String comparison - "1609459200" > "999999999" lexically wrong. Use numbers. 32-bit overflow - timestamps after 2038. Use 64-bit. Leap seconds - Unix time ignores them (occasionally 61 seconds in minute). Not an issue for most apps. Float vs integer - precision loss in milliseconds. Use integers. Negative timestamps valid (pre-1970 dates). Forgetting to multiply/divide by 1000 when converting to JavaScript. This tool validates input and prevents common conversion errors.
Convert to Date object then format per locale. US: MM/DD/YYYY (01/15/2025), Europe: DD/MM/YYYY (15/01/2025), ISO 8601: YYYY-MM-DD (2025-01-15 - unambiguous). Time: 12-hour (3:30 PM) vs 24-hour (15:30). JavaScript: new Intl.DateTimeFormat("en-US").format(date). Libraries: date-fns, Moment.js (deprecated), Luxon, Day.js. Include timezone in display: "Jan 15, 2025 3:30 PM EST". Best practice: let user set preference or detect from browser locale (navigator.language). API responses: always use ISO 8601 with timezone: 2025-01-15T15:30:00Z. This tool formats timestamps in common regional formats with timezone support.
Windows FILETIME is a 64-bit value representing 100-nanosecond intervals since January 1, 1601 00:00:00 UTC (Windows epoch). Used throughout Windows: PE file headers (TimeDateStamp), registry timestamps, NTFS metadata, event logs. Malware analysts need FILETIME because: PE compilation timestamps reveal when malware was built, registry modifications show persistence mechanisms, file system timestamps indicate infection timeline, Windows event correlation requires timestamp synchronization. Example: FILETIME 133774656000000000 (decimal) = 0x1DA3A7E8E3F0000 (hex) = 2024-12-04. Common in: exe/dll headers, Windows Registry forensics, memory dumps, NTFS analysis. This tool converts FILETIME ↔ Unix ↔ human-readable for rapid malware timeline reconstruction.
Conversion formula: Unix = (FILETIME / 10000000) - 11644473600, where 10000000 converts 100-ns intervals to seconds, 11644473600 is seconds between 1601 and 1970. Reverse: FILETIME = (Unix + 11644473600) × 10000000. Example: PE header TimeDateStamp 0x65703B80 (hex) = 1701892992 (Unix seconds) = Dec 6, 2023. FILETIME formats: decimal (18 digits: 133774656000000000), hexadecimal (0x prefix: 0x1DA3A7E8E3F0000). This tool supports both: select input format (Unix/FILETIME-decimal/FILETIME-hex), paste value, get all conversions instantly. Auto-detect: values > 100000000000000 assumed FILETIME, 0x prefix = hex. Batch mode: paste multiple timestamps for forensic timeline analysis.
Common FILETIME locations: PE headers - IMAGE_FILE_HEADER.TimeDateStamp (Unix 32-bit, not FILETIME but needs conversion), debug directory timestamps. Registry - HKLM\SOFTWARE modification times, persistence keys (Run, RunOnce). NTFS - (creation, modification, MFT change, access times), timestamps. Event logs - Windows Event Log .evtx entries. Memory dumps - process creation times, thread start times. Prefetch files - execution timestamps. Tools extract these as hex/decimal - this converter translates to readable dates. Malware timeline: compile time → dropper execution → persistence installation → C2 communication. Analyst workflow: extract timestamps from tools (PEStudio, Registry Explorer, MFTECmd), paste into batch converter, build attack timeline.