LDAP / FILETIME Converter — 18-Digit Windows Timestamps ↔ Date

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 lastLogon vs lastLogonTimestamp, 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.

Common Active Directory attributes that use FILETIME

Microsoft documents Active Directory date/time values such as LastLogon, LastLogonTimestamp, and LastPwdSet as large integers that convert from 100-nanosecond intervals since 1601-01-01 UTC (Microsoft Learn).

• lastLogon: The last logon time recorded by a specific domain controller. Query all DCs for the most accurate result.
• lastLogonTimestamp: A replicated logon timestamp used for stale-account discovery; it may lag behind real activity.
• pwdLastSet: The time the account password was last set. A value of 0 can force a password change.
• accountExpires: Account expiration time. 0 and 0x7FFFFFFFFFFFFFFF commonly mean Never.
• badPasswordTime: The latest bad password attempt time recorded for the account.
• lastLogoff: Legacy logoff field. In many environments it is unused or left at 0.
• lockoutTime: Time when the account was locked out; 0 means it is not currently locked.
• whenCreated: Object creation time. This is often exposed as LDAP GeneralizedTime rather than Integer8 FILETIME.

Convert LDAP/FILETIME in PowerShell

To convert a FILETIME value to UTC:

[DateTime]::FromFileTimeUtc(133323840000000000)

To convert a UTC date back to FILETIME:

(Get-Date "2025-03-01T10:30:00Z").ToFileTimeUtc()

Convert LDAP/FILETIME in Excel

If the FILETIME value is in A1, use:

=(A1/864000000000)-109205

Then format the result cell as Date/Time. The divisor converts 100-ns ticks to days, and 109205 adjusts Excel’s date system to the Windows FILETIME epoch.

LDAP timestamp formats: FILETIME vs GeneralizedTime

LDAP and Active Directory tools can show more than one timestamp format. An 18-digit integer is usually Windows FILETIME / Integer8, while a compact year-month-day string is usually LDAP GeneralizedTime.

• 133323840000000000 = Windows FILETIME / Integer8
• 20260517115858Z = LDAP GeneralizedTime

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.