Why is an Active Directory timestamp 18 digits long?

Attributes such as lastLogonTimestamp and pwdLastSet store a Windows FILETIME: the number of 100-nanosecond intervals since 1 January 1601 UTC. Ten million intervals make a second, so any date in this century is an 18-digit number such as 133452864000000000 (24 November 2023, 08:00 UTC).

Should I trust lastLogonTimestamp for the last time someone signed in?

Only to within about two weeks. lastLogonTimestamp is replicated between domain controllers but only updated when the stored value is older than the msDS-LogonTimeSyncInterval setting — 14 days by default, minus a random offset of up to five days. lastLogon is exact but kept separately on each domain controller. For an exact time, use the logon events themselves.

What does 9223372036854775807 or 0 mean in accountExpires?

Both mean the account never expires: they are sentinel values, not dates. In pwdLastSet, 0 means the user must change the password at the next logon.

Are the converted times UTC?

Yes. Every format here counts from a fixed instant in UTC, so the converted value is shown in UTC first and then in your browser’s local time zone. Dates without a zone, such as 2026-10-15 12:00:00, are read as UTC, which is how most security logs write them.

LDAP, FILETIME and Unix timestamp converter

Paste a timestamp in any of the formats security logs and Active Directory use — an 18-digit lastLogonTimestamp, a hex FILETIME, Unix seconds or milliseconds, a Chrome history time — or a date. The format is detected from the value, and the result is shown in every other format.

Try:

The formats

Format	Counts	Looks like	Where you see it
Windows FILETIME / AD timestamp	100-ns intervals since 1601-01-01 UTC	18 digits (decimal) or 16 hex	Active Directory lastLogon, lastLogonTimestamp, pwdLastSet, accountExpires, badPasswordTime; NTFS and registry times; DFIR tool output
Unix time	seconds (or ms, µs, ns) since 1970-01-01 UTC	10, 13, 16 or 19 digits	Linux and cloud logs, CloudTrail and JSON exports, Okta, most APIs
Chrome / WebKit time	microseconds since 1601-01-01 UTC	17 digits	Chrome and Edge history and cookie databases
Mac absolute time (Cocoa)	seconds since 2001-01-01 UTC	9 digits	macOS and iOS databases (Core Data, Safari, iMessage)
Excel / OLE Automation date	days since 1899-12-30, fraction = time of day	about 45,000 for recent dates	Spreadsheets and CSV exports that went through Excel

Active Directory timestamps in an investigation

Account attributes are where these 18-digit numbers come from, and each one answers a different question. pwdLastSet dates the last password change — the first thing to check when an account is suspected of being taken over and then “secured” by the attacker. badPasswordTime is the last failed password on the domain controller that answered the query. lastLogon is exact but local to each domain controller, while lastLogonTimestamp is replicated but can lag by up to two weeks, so neither replaces the logon events (4624, 4625, and Kerberos 4768/4771) for a timeline.

To convert the same values in a script or a query:

# PowerShell
[datetime]::FromFileTimeUtc(133452864000000000)

# Windows command line
w32tm /ntte 133452864000000000

// KQL (Microsoft Sentinel): one tick is 100 ns
print datetime(1601-01-01) + 133452864000000000 * 1tick

Why the same instant has so many numbers

Every format counts the same thing — time since a fixed starting point — with a different start and a different unit. Windows FILETIME and Chrome start in 1601, the first year of the 400-year Gregorian cycle Windows uses; Unix starts in 1970; Apple’s Cocoa clock starts in 2001; Excel counts days from the end of 1899. The digit count is usually enough to tell them apart, which is how the converter picks the most likely reading. When two readings are plausible — a 9-digit number can be Cocoa time or early-1990s Unix time — both are shown.

Questions

Why is an Active Directory timestamp 18 digits long?: Attributes such as lastLogonTimestamp and pwdLastSet store a Windows FILETIME: the number of 100-nanosecond intervals since 1 January 1601 UTC. Ten million intervals make a second, so any date in this century is an 18-digit number such as 133452864000000000 (24 November 2023, 08:00 UTC).
Should I trust lastLogonTimestamp for the last time someone signed in?: Only to within about two weeks. lastLogonTimestamp is replicated between domain controllers but only updated when the stored value is older than the msDS-LogonTimeSyncInterval setting — 14 days by default, minus a random offset of up to five days. lastLogon is exact but kept separately on each domain controller. For an exact time, use the logon events themselves.
What does 9223372036854775807 or 0 mean in accountExpires?: Both mean the account never expires: they are sentinel values, not dates. In pwdLastSet, 0 means the user must change the password at the next logon.
Are the converted times UTC?: Yes. Every format here counts from a fixed instant in UTC, so the converted value is shown in UTC first and then in your browser’s local time zone. Dates without a zone, such as 2026-10-15 12:00:00, are read as UTC, which is how most security logs write them.

Building a timeline from several logs?

LogTriage normalises timestamps from 51 log formats into one UTC timeline, groups the events into attack sessions and writes the incident report.

Try Live Demo → Analyze your own logs