Timestamp Converter

Convert between Unix timestamps and human-readable dates instantly — plus Windows FILETIME, .NET ticks, LDAP/AD, Chrome WebKit, and Excel OADate. Paste any value and the format is auto-detected, with one-click copy.

Converter

Live Unix Timestamp

Seconds0

Milliseconds0

Timestamp → Date

Date → Timestamp

What Is a Unix Timestamp?

A Unix timestamp (also called Unix epoch time or POSIX time) is the number of seconds elapsed since 1970-01-01 00:00:00 UTC — the Unix epoch. It's the most common way to represent a point in time in programming.

For example, 1700000000 corresponds to November 14, 2023, 22:13:20 UTC.

Unix timestamps are:

• Timezone-independent — always measured in UTC
• Continuous — no leap seconds in most implementations
• Compact — a single integer vs. a full date string

Seconds vs Milliseconds

Unix timestamps come in two common resolutions:

	Seconds	Milliseconds
Example	1700000000	1700000000000
Precision	1 second	1 millisecond
Used by	Unix/Linux APIs, most databases	JavaScript (Date.now()), Java, logging systems
Digits	~10 digits	~13 digits

How to tell them apart: If the number has 13+ digits, it's milliseconds. This converter auto-detects the resolution — just paste the number and it figures out the rest.

Common Use Cases

• Debugging logs — Convert timestamps in server logs to readable times to trace events
• API integrations — Many REST APIs use Unix timestamps for date fields
• Database queries — Query records by time range using epoch values
• Scheduling — Calculate delays or schedule future events using timestamp arithmetic
• UUID v7 — UUID v7 embeds a millisecond Unix timestamp in its first 48 bits; decode it to see when the UUID was created
• Active Directory admin — Convert lastLogon, pwdLastSet, and accountExpires LDAP timestamps to readable dates for user audits
• Excel / Office automation — Decode OADate serial numbers when interop'ing with spreadsheets and DateTime.FromOADate
• Chrome forensics — Read History and Cookies SQLite WebKit timestamps for debugging or digital forensics

Windows FILETIME

Windows FILETIME is a 64-bit value counting 100-nanosecond intervals since 1601-01-01 00:00:00 UTC. It's the native time format of the Win32 API, the NTFS file system, and COM/OLE.

A FILETIME struct stores the value as two 32-bit DWORDs: dwLowDateTime and dwHighDateTime. You'll encounter it in GetFileTime(), CoFileTimeNow(), and NTFS master file table (MFT) records.

Conversion formula:

unix_seconds = (filetime / 10000000) - 11644473600

For example, 133592755356230000 → 2024-05-04 04:32:15 UTC. This converter auto-detects 18-digit values below ~3 × 10¹⁷ as FILETIME.

.NET DateTime Ticks

.NET Ticks is a 64-bit signed integer counting 100-nanosecond intervals since 0001-01-01 00:00:00 UTC (year 1). It's the backing store for DateTime in C# and .NET, accessible via DateTime.Now.Ticks.

The range covers dates from 0001-01-01 to 9999-12-31 — a single long value of up to ~3.16 × 10¹⁸. Unlike FILETIME (which is 1601-based), .NET ticks start at year 1 to avoid negative values and simplify calendar math.

For example, 638514336000000000 ticks → 2024-05-16 00:00:00 UTC. Values at or above ~3 × 10¹⁷ are detected as .NET ticks; below that threshold, FILETIME is more likely.

LDAP / Active Directory Timestamp

LDAP timestamps (used by Microsoft Active Directory) are numerically identical to FILETIME — 100-nanosecond intervals since 1601-01-01 UTC. The difference is purely the context: AD attributes such as lastLogon, lastLogonTimestamp, pwdLastSet, and accountExpires store FILETIME values under the LDAP schema.

AD admins routinely convert these to audit user activity and password expiry. In PowerShell:

[DateTime]::FromFileTime($value).ToString('yyyy-MM-dd HH:mm:ss')

For example, 132514560000000000 → 2020-12-03 00:00:00 UTC. An accountExpires of 9223372036854775807 (Int64.MaxValue) means "never expires".

Chrome / WebKit Timestamp

Chrome and WebKit timestamps count microseconds (not 100-nanoseconds) since 1601-01-01 UTC. They appear in Chrome's History, Cookies, and Login Data SQLite databases — useful for debugging, forensics, and data recovery.

Because the unit is μs (not 100ns), the values are 10× smaller than FILETIME for the same instant. Current-era values are 17 digits (~1.3 × 10¹⁶).

To query Chrome history in SQL:

SELECT datetime(time / 1000000 - 11644473600, 'unixepoch') AS visit_time
FROM urls ORDER BY visit_time DESC LIMIT 10;

For example, 13317696000000000 → 2023-01-09 00:00:00 UTC.

Microsoft OADate / Excel Serial

OADate (OLE Automation Date) is a double counting days since 1899-12-30. The fractional part represents the time of day (0.5 = noon). Excel, Google Sheets, and Office automation all use this serial format internally.

Why 1899-12-30 and not 1900-01-01? Excel intentionally replicates a 1900 leap-year bug (1900 was not a leap year, but Lotus 1-2-3 treated it as one). Shifting the epoch back by two days keeps Excel dates compatible with the legacy bug.

For example, 45678.5 → 2025-01-21 12:00:00. In C#: DateTime.FromOADate(45678.5). In Excel: =DATE(2025,1,21) returns 45678.

FAQ

What is the Year 2038 problem? Unix timestamps in 32-bit signed integers max out at 2147483647 (January 19, 2038, 03:14:07 UTC). Systems still using 32-bit time_t will overflow. Most modern systems have already moved to 64-bit timestamps, which won't overflow for 292 billion years.

Does this tool handle timezones? Unix timestamps are inherently UTC. This converter shows both the UTC representation and your browser's local timezone, so you always get both perspectives.

Can I use negative timestamps? Yes. Negative Unix timestamps represent dates before the epoch (1970-01-01 00:00:00 UTC). For example, -86400 is December 31, 1969, 00:00:00 UTC — exactly one day before the epoch.

What's the difference between FILETIME and LDAP timestamps? Numerically, nothing — both are 100-nanosecond intervals since 1601-01-01 UTC. "FILETIME" is the Win32/COM name; "LDAP timestamp" refers to the same value stored in Active Directory attributes like lastLogon. Use the same conversion formula for both.

Why does .NET DateTime.Ticks start at year 1? .NET's calendar starts at 0001-01-01 (the conventional start of the Gregorian calendar) so that all valid dates produce positive tick values. This avoids the sign-handling complexity of FILETIME's 1601 epoch and simplifies date arithmetic across the full 0001–9999 range.

Why is the OADate epoch December 30, 1899? Excel inherited a bug from Lotus 1-2-3 that treated 1900 as a leap year (it was not). To keep dates like March 1, 1900 matching between Excel and reality, the OLE Automation epoch was set to 1899-12-30 — two days before the nominal "January 1, 1900" start, compensating for the phantom February 29, 1900.