1601 kicks off a 400-year cycle
Windows chose 1601-01-01 because Gregorian leap years repeat every 400 years. Starting at a cycle boundary keeps the math neat.
Calendar math
LDAP / FILETIME Converter — 18-Digit Windows Timestamps ↔ Date
Options & Quick
Results always include UTC; this controls the extra local view.
AD “Never”:
0 or 9223372036854775807 (0x7FFFFFFFFFFFFFFF)1) LDAP / FILETIME → Date
Counts 100-ns intervals since 1601-01-01T00:00:00Z.
2) Date → LDAP / FILETIME
Interpreted in your current local time zone.
If a zone/offset is provided, it will be respected.
What is LDAP / Windows FILETIME?
Windows FILETIME (often called LDAP time, NT time, or NTTIME) is a 64-bit signed
integer used by Windows and Active Directory to represent absolute moments in time. The value counts the
number of 100-nanosecond intervals (a.k.a. “ticks”) that have elapsed since the
Windows epoch: 1601-01-01T00:00:00Z (UTC). Many directory attributes use this format,
including lastLogonTimestamp, pwdLastSet, accountExpires, badPasswordTime,
and more.
Why does Windows/LDAP use FILETIME?
FILETIME provides a compact, monotonic, time zone–agnostic representation with sub-second precision (100 ns). Because the value is UTC-based, it avoids daylight saving time pitfalls and regional formatting inconsistencies. In LDAP/AD, these values are stored as 64-bit integers and can be transported or indexed efficiently across systems.
How conversion works (the math)
Compared to the UNIX epoch (1970-01-01T00:00:00Z), the Windows epoch starts earlier. The exact gap is
11,644,473,600,000 milliseconds (that is, 11644473600 seconds). Conversion is therefore a simple
offset plus a unit change:
- FILETIME → milliseconds since 1970:
ms = (filetime / 10,000) − 11,644,473,600,000 - Milliseconds since 1970 → FILETIME:
filetime = (ms + 11,644,473,600,000) × 10,000
Our converter performs this arithmetic safely with BigInt, then renders human-readable results in UTC
and your chosen time zone. Because the underlying value is UTC, DST never alters the stored number—only
the display string changes.
Special “Never” values in Active Directory
Some AD attributes use sentinel values to mean no expiry or not set. The most common are:
0— often interpreted as Never (e.g.,accountExpires).9,223,372,036,854,775,807(0x7FFFFFFFFFFFFFFF) — the maximum 64-bit signed integer, also used to indicate Never.
The tool detects and labels these values automatically so you don’t mistake them for real dates.
Hex or decimal? Endianness? Precision?
FILETIME values are frequently shown as 18-digit decimals in LDAP tools and logs. Some APIs and
forensic utilities present the same value in hexadecimal (with or without a 0x prefix).
Both point to the same 64-bit number, and this page accepts either form. Internally, Windows APIs expose
FILETIME as two 32-bit parts; when serialized in binary structures they are little-endian, but LDAP/AD
queries typically surface them as regular big-number integers—no byte-swapping is needed when you paste a
string here.
JavaScript’s Number type cannot precisely represent all 64-bit integers. To avoid rounding, this
converter uses BigInt for the math and only converts to Date once the value is safely
in milliseconds, preserving accuracy for very large timestamps.
Common pitfalls & tips
- Local vs UTC: FILETIME is UTC. If a string lacks an offset, your browser may interpret it as local time when converting back.
- DST & leap seconds: DST does not change the stored value. Windows/UNIX time generally ignores leap seconds.
- Range: Extremely large FILETIME values may exceed the practical range of the JavaScript
Date(≈ ±8.6e15 ms). The tool warns if a value is out of range. - Audit/forensics: When investigating
lastLogonvslastLogonTimestamp, remember replication behavior; the precise tick still converts the same way.
Tip: Need a quick mental check? Divide the FILETIME by 10,000 to get milliseconds since 1601,
subtract 11,644,473,600,000, and compare the result to today’s epoch milliseconds.
Or just paste it above and let the converter handle the details—privately, in your browser.
5 Fun Facts about LDAP / FILETIME Timekeeping
10,000,000 ticks each second
FILETIME counts 100-ns ticks—the same tick size .NET uses—so there are ten million ticks per second and 864 billion in a day.
Precision
Magic offset constant
Subtract hex 0x01B21DD213814000 (116444736000000000 decimal) from a FILETIME to land exactly on the Unix epoch.
Converter shortcut
"Never" is year 30828
The AD sentinel 0x7FFFFFFFFFFFFFFF points to a date around the year 30,828—far enough away to stand in for infinity.
AD trivia
Dual personalities
FILETIME travels as two little-endian 32-bit parts in Windows structs, but LDAP surfaces it as one big integer—no byte swap needed when you paste values here.
Interop
LDAP / FILETIME Converter: FAQs
What’s the relationship to UNIX epoch?
FILETIME uses a different epoch (1601-01-01 UTC) and unit (100 ns). The tool converts via precise arithmetic with
BigInt and an exact epoch offset so it’s safe for large values.
Does DST affect LDAP/FILETIME values?
No. LDAP/FILETIME values encode an absolute moment in UTC. Only the display in your selected time zone changes with DST.
Can I copy numeric and hex outputs?
Yes. Click the copy chips beside each output to copy decimal, hexadecimal, and ISO-8601 UTC.