LDAP Timestamp Converter
Convert between LDAP/Active Directory timestamps and human-readable dates. LDAP timestamps count 100-nanosecond intervals since January 1, 1601.
Convert
The LDAP timestamp converter translates between LDAP/Active Directory timestamps and human-readable dates. LDAP and Windows store time as the number of 100-nanosecond intervals since January 1, 1601 (UTC), which produces 18-digit integers that look nothing like a Unix timestamp. The converter handles the format in both directions and also shows the equivalent Unix timestamp for use in non-Windows systems.
What an LDAP Timestamp Actually Is
LDAP timestamps - also called Windows FILETIME, Active Directory NTFS time, or simply "100-nanosecond intervals since 1601" - are an 18-digit integer that counts how many 100ns ticks have elapsed since January 1, 1601 at 00:00:00 UTC. A current timestamp looks like 133617408000000000. The format is used by:
- Active Directory: the lastLogon, accountExpires, badPasswordTime, pwdLastSet, lastLogonTimestamp, and lockoutTime attributes all use this format.
- Windows NTFS: file creation, modification, and access times are stored as FILETIME structures, which are the same format as LDAP timestamps.
- LDAP servers and exports: Microsoft-flavored LDAP directory dumps and CSV exports show timestamps in this format unless explicitly converted.
- Kerberos tickets: some fields in Kerberos messages reuse the same 1601-based counter.
The format exists because Microsoft chose 1601 as the start of the modern Gregorian calendar cycle when designing Windows NT, and 100-nanosecond intervals give plenty of resolution for filesystem and authentication events. Linux, macOS, and most web services use Unix timestamps (seconds since 1970) instead, so cross-platform tools need to convert between the two.
How the Converter Works
Enter an LDAP timestamp into the LDAP Timestamp field and the matching date appears in the result card. Enter a calendar date and time into the Date and Time fields and the LDAP timestamp appears. Both directions show the date in three formats simultaneously plus the Unix timestamp for systems that need a 10-digit value:
- LDAP Timestamp: the 18-digit integer as stored in Active Directory or NTFS.
- Unix Timestamp: the same moment as a 10-digit Unix integer, useful for migrating data from a Windows system to a Linux service.
- Full Date and Time: readable date in your browser's local timezone.
- ISO 8601: standardized international format, useful for logs and APIs.
The conversion formula between the two timestamp formats is straightforward: subtract 11,644,473,600 from the LDAP timestamp (the seconds between 1601 and 1970) divided by 10,000,000 (since LDAP uses 100ns intervals). The converter does this math for you and rounds correctly so a directly entered moment converts cleanly to and from both formats.
When You Need an LDAP Converter
Anyone who reads Active Directory exports, NTFS forensics dumps, or Windows event logs will eventually run into a column of 18-digit numbers that need to be human-readable. Common scenarios:
- User account auditing: read the lastLogon, lastLogonTimestamp, or pwdLastSet attribute to see when a user last authenticated or rotated their password.
- Lockout investigations: decode lockoutTime and badPasswordTime to build a timeline of failed login attempts.
- Account expiry checks: the accountExpires attribute holds either a future LDAP timestamp or one of two special values (0 or 9223372036854775807, meaning "never expires").
- Forensic analysis: NTFS file timestamps in tools like Autopsy or EnCase are shown as FILETIME values; converting them gives the actual incident timeline.
- Data migration: converting an LDAP-formatted column to Unix timestamps lets you import the data into a non-Windows database without writing custom conversion code.
For bulk LDAP timestamp conversion, the batch converter handles many values at once but expects Unix timestamps; use the LDAP converter row by row when working with Windows exports, or write a quick script that subtracts 11644473600 and divides by 10000000 to convert the whole column to Unix first. To match a converted timestamp against a system clock, the main converter or epoch clock show the same moment in every common format.
Common Special Values
Active Directory uses two well-known sentinel values that the converter handles correctly:
- 0: means "never" - the attribute has never been set. A pwdLastSet of 0 means the user has never set a password (or is required to change it on next login). A lastLogon of 0 means the user has never logged into the domain.
- 9223372036854775807 (Int64.MaxValue): means "no expiration" - the attribute is intentionally set to the maximum signed 64-bit integer to indicate "the end of time". Common in accountExpires for service accounts that should never expire automatically.
Both special values appear as the year 1601 or the year 30828 when naively converted, so it is important to check for them before treating the result as a real date. The converter shows the raw conversion; deciding whether to interpret a 1601 result as "never set" depends on which attribute you are reading.
Frequently Asked Questions
An LDAP timestamp is an 18-digit integer that counts 100-nanosecond intervals since January 1, 1601 at 00:00:00 UTC. It is the format Active Directory and Windows NTFS use for time attributes like lastLogon, pwdLastSet, and file creation times. Also known as Windows FILETIME or NTFS time. The converter translates between this format and standard Unix timestamps or calendar dates.
Microsoft chose 1601 when designing Windows NT because it is the start of the first full 400-year cycle of the Gregorian calendar, which makes calendar arithmetic cleaner over long timeframes. Unix chose 1970 because it was a recent round year when the Unix operating system was created. The two formats serve the same purpose but with different reference points and different resolutions (seconds vs 100 nanoseconds).
Divide the LDAP timestamp by 10,000,000 (to convert 100-nanosecond intervals to seconds) and then subtract 11,644,473,600 (the seconds between Jan 1, 1601 and Jan 1, 1970). The formula is: unix_ts = (ldap_ts / 10000000) - 11644473600. The converter does this math automatically and also reports the Unix timestamp in the result so you can verify.
0 means the attribute has never been set or applies only to specific cases (a pwdLastSet of 0 means the user must change password at next login). 9223372036854775807 is the maximum signed 64-bit integer and means "never expires", commonly seen in accountExpires for service accounts. Treat these values as sentinels rather than real dates.
The most common ones are lastLogon, lastLogonTimestamp, pwdLastSet, accountExpires, badPasswordTime, lockoutTime, and creationTime. Some AD attributes use a different ISO-like string format (whenCreated, whenChanged) instead - those look like 20260528120000.0Z and need a different conversion. If your value is an 18-digit number, it is an LDAP timestamp; if it is a 14-digit string followed by .0Z, it is the AD generalized time format.
Yes, they are the same format. FILETIME is the name Microsoft uses for the 64-bit integer counting 100-nanosecond intervals since Jan 1, 1601. LDAP timestamp is the name used when the same value appears in Active Directory attributes. NTFS file timestamps also use this format. All three are interchangeable and the converter handles them identically.
A converted date of January 1, 1601 means the source value was 0 (never set). A date around 30828 means the source was the maximum 64-bit integer (never expires). Both are sentinel values used by Active Directory rather than real dates. Check the source attribute before treating the conversion as an event timestamp.
LDAP timestamps are always stored in UTC, the same as Unix timestamps. The converter displays the result in your browser's local timezone for readability, but the underlying integer represents an absolute UTC moment. This matches how Active Directory stores all time attributes regardless of the server or client timezone.
The format has 100-nanosecond resolution in theory, which is 10,000 times more precise than a Unix timestamp in seconds. In practice the kernel and the LDAP server round to system clock granularity (15ms on older Windows, 1ms on newer versions), so the trailing digits often look round even though the format supports more detail.
No. LDAP timestamps are stored as 64-bit signed integers, which can hold dates up to the year 30828. The 32-bit overflow that affects Unix timestamps in 2038 has no equivalent in LDAP/FILETIME. Active Directory and NTFS will keep working at their normal precision well beyond any practical horizon.