Guide
Converting Active Directory and Windows FILETIME timestamps
Active Directory, the Windows registry, NTFS and many Windows logs store dates as large integers such as 134377920000000000. They are FILETIME values, and without converting them you cannot tell when a password was set or an account last logged in. This converter turns them into dates and turns dates back into the numbers you need for LDAP filters and scripts.
What a FILETIME counts
A FILETIME is the number of 100-nanosecond intervals since 1 January 1601, 00:00 UTC. The odd starting point is the beginning of the 400-year Gregorian calendar cycle in which Windows NT was designed, which makes leap-year arithmetic simple. The value fits in a 64-bit integer and gives sub-microsecond precision for dates far into the future. Between that epoch and the Unix epoch of 1970 lie exactly 11,644,473,600 seconds, which is the constant every conversion uses.
Where you meet them
In Active Directory, pwdLastSet, lastLogon, lastLogonTimestamp, badPasswordTime, lockoutTime and accountExpires are all FILETIME values, and PowerShell’s Get-ADUser shows them raw unless you ask for the converted properties. They also appear in Windows event data, registry values, NTFS metadata and forensic tools, sometimes written as hexadecimal; the converter accepts decimal and 0x hex.
Special values
Two values do not mean dates. 0 in accountExpires means the account never expires, and in pwdLastSet it means the user must change the password at the next logon. 9223372036854775807, the largest signed 64-bit number, also means “never” for accountExpires, typically after an expiry date was set and later cleared. The converter explains both instead of showing a date in 1601 or in the year 30828.
Generalized Time
Some attributes, notably whenCreated and whenChanged, use LDAP Generalized Time from RFC 4517 instead: a string such as 20261030091500.0Z, meaning year, month, day, hour, minute and second in UTC. Paste one and it is converted the same way.
A worked example
134377920000000000 converts to 2026-10-30T00:00:00.000Z, midnight UTC on 30 October 2026. The Generalized Time 20261030091500.0Z is 2026-10-30T09:15:00.000Z. Going the other way, the date 2026-10-30 00:00:00 UTC gives the FILETIME 134377920000000000, the hex value 0x01DD68019B418000, the PowerShell check [DateTime]::FromFileTimeUtc(134377920000000000) and the filter (lastLogonTimestamp>=134377920000000000) for accounts that have logged in since then.
Finding stale accounts
To list accounts that have not logged in for 90 days, convert the date 90 days ago to a FILETIME and search for lastLogonTimestamp values below it: (&(objectCategory=person)(objectClass=user)(lastLogonTimestamp<=…)). Combine it with a check that the account is enabled, and review the list before disabling anything.
The replication caveat
lastLogonTimestamp is designed to be approximate. To limit replication traffic, a domain controller only updates it when the stored value is older than a randomised interval of about 9 to 14 days. It is fine for finding accounts unused for months, not for knowing when someone last signed in. For that, query lastLogon, which is exact but not replicated, on every domain controller and take the newest value.
Related tools
- Timestamp Converter handles Unix seconds and milliseconds.
- Cocoa Timestamp Converter reads Apple’s 2001-based dates.
- GPS Time Converter converts satellite time with leap seconds.
- Time Zone Converter shows the UTC result in other zones.
Checked against the current version of the LDAP / FILETIME Converter on .