Free · No account · Works in your browser
LDAP Timestamp
Active Directory LDAP / FILETIME converter
LDAP Timestamp
Enter values below, then calculate.
The LDAP timestamp converter translates Windows FILETIME values used in Active Directory, LDAP directories, and many Microsoft APIs into readable datetimes — and back. Attributes like lastLogonTimestamp, pwdLastSet, and whenCreated store 100-nanosecond intervals since 1601-01-01 UTC, not Unix seconds. Paste the long integer from PowerShell, ldapsearch, or event logs to decode; enter a civil date to generate FILETIME for test fixtures.
FILETIME versus Unix epoch
Unix time counts seconds since 1970-01-01 UTC. FILETIME counts 100-nanosecond ticks since 1601-01-01 UTC — the same epoch as OLE automation dates in Excel internals. A typical AD attribute shows eighteen digits. Feeding that into a Unix converter yields nonsense centuries off target.
Use the Unix timestamp converter for ten-digit POSIX values. Hex memory dumps of Unix ints belong on hex timestamp. Spreadsheet serial days use the Excel date converter.
Common Active Directory attributes
lastLogonTimestamp replicates loosely — decode for ballpark inactive account reports, not second-accurate security. pwdLastSet shows password age policies. accountExpires uses FILETIME with sentinel values for “never expires.” whenChanged and whenCreated audit object lifecycle during 2026 migrations.
PowerShell returns some attributes as DateTime objects automatically; raw ldapsearch and CSV exports from third-party tools often leave the integer visible — that is when this page earns its keep.
Decoding workflow
Copy the integer exactly — no commas from locale formatting. Zero and max uint64 sentinels map to special meanings documented in Microsoft schema; decode here to see whether a value is “never” or an actual instant. Compare pwdLastSet across service accounts before rotation campaigns.
For lastLogon versus lastLogonTimestamp, know that lastLogon is not replicated and may differ per domain controller — FILETIME decode does not resolve DC selection issues, only format math.
Worked examples
Example A: compliance report lists pwdLastSet as 133456789012345678. Decode to civil date, compare against ninety-day policy, export username list for forced reset.
Example B: stale computer object whenCreated decodes to pre-cloud era — candidate for cleanup script after verifying no active login via separate telemetry.
Example C: building SAML metadata expiry from accountExpires sentinel — decode confirms whether 9223372036854775807 truly means no expiry in your forest functional level.
Encoding dates for LDAP modify operations
Test environments need valid FILETIME when seeding users with expiring passwords. Encode midnight UTC on a chosen day, paste into LDIF or PowerShell Set-ADUser -AccountExpirationDate after verifying cmdlet accepts DateTime instead of raw int. Round-trip decode once before bulk import.
Scheduled account terminations aligned with fiscal close should use UTC midnight consistent with HRIS offboarding tickets — cross-check dates on the yearly 2026 calendar.
PowerShell and ldapsearch tips
[datetime]::FromFileTime() in PowerShell mirrors this page — use the browser tool when you cannot run scripts on a jump box. ldapsearch -LLL output may truncate large integers in narrow terminals — widen buffer or export to file before copy.
Azure AD sync transforms some attributes before on-prem display — confirm whether your CSV came from hybrid connector or native cloud export before assuming FILETIME format.
Security and compliance use cases
Inactive account sweeps decode lastLogonTimestamp to prioritize disablement. Privileged group reviews compare pwdLastSet against break-glass policy. Incident response correlates compromised user pwdLastSet changes with SIEM Unix epoch lines — normalize both to UTC ISO strings before timeline merge.
Never paste production FILETIME dumps with usernames into public tickets — redact identifiers when asking vendors for help.
Precision and overflow notes
100-nanosecond resolution exceeds what most audit policies require — display to second precision unless investigating sub-second replication skew. FILETIME supports dates far beyond 2026; int64 storage avoids Unix 2038 issues for AD-native fields, though downstream apps may still assume 32-bit.
JavaScript Number loses integer precision above 2^53 — very large FILETIME values should be handled in BigInt libraries in code; this page covers typical AD-range integers accurately.
Group Policy and replication lag
lastLogonTimestamp replicates slowly by design — decoding shows stored FILETIME, not live login. Pair decode output with recent lastLogon from single DC when triaging stale account reports during 2026 audits.
Fine-grained password policies reading pwdLastSet across OUs export CSV — batch-decode top fifty rows in spreadsheet helper column before sorting password-age histograms for compliance slides.
Migration and sunset projects
Cloud directory migration cutovers compare on-prem whenCreated FILETIME with cloud createdDateTime ISO strings — convert both to UTC table side by side to prove object order preserved. Legacy NT4 exports with odd sentinels decode here to distinguish “never set” from real 1601-era placeholders.
Service account password rotation runbooks list pwdLastSet decode targets — automate PowerShell where possible, use browser tool when jump box blocks scripts.
Disaster recovery and tombstone lifetimes
Active Directory tombstone lifetime and deleted-object retention publish as FILETIME-adjacent intervals in some docs — decode pwdLastSet on restored objects after forest recovery drill to confirm password policy reapplied. Cross-forest trust cutover runbooks list lastLogonTimestamp decode thresholds for disable-not-delete accounts staged in 2026 migration.
Help desk tickets citing “account expired yesterday” need accountExpires decode plus timezone — midnight UTC expiry displays prior evening in US offices.
Azure AD Connect sync attributes
Hybrid identity deployments map on-prem pwdLastSet through sync rules — decode cloud-exported shadow copy when troubleshooting password hash sync delay in 2026 cutover. Guest user invitation redemption timestamps in ISO may need comparison with on-prem whenCreated FILETIME for B2B join latency tickets.
Identity governance certifications listing stale account criteria should cite decoded pwdLastSet threshold date in policy PDF — auditors match spreadsheet column to AD export raw integer without hand conversion errors during 2026 recertification cycle.
SOC2 evidence binders paste pwdLastSet decode sample alongside raw export hash — reviewers confirm identity team interpreted FILETIME correctly without PowerShell access to production forest during 2026 audit window.
Tier-1 help desk paste pwdLastSet decode into ticket note so tier-2 avoids re-asking customer for raw integer.
Related tools
POSIX epoch: Unix timestamp. UUID clocks: UUID time. Converter index: converters hub.
Frequently asked questions
What is an LDAP or FILETIME timestamp?
It is a 64-bit integer counting 100-nanosecond intervals since 1 January 1601 UTC, used in Active Directory and many Windows APIs. It is not Unix epoch seconds. Attributes like pwdLastSet and lastLogonTimestamp appear as long integers in ldapsearch CSV exports until converted to readable dates.
How is FILETIME different from Unix time?
Unix time uses seconds since 1970-01-01 UTC. FILETIME uses finer ticks from 1601-01-01 UTC. The numeric values differ by orders of magnitude — an eighteen-digit FILETIME pasted into a Unix converter produces meaningless dates. Always identify the source schema before choosing a tool.
Why does lastLogonTimestamp look stale?
lastLogonTimestamp replicates on a delay and is updated only intermittently to reduce domain controller load — often up to fourteen days behind actual login. Decoding shows the stored FILETIME accurately, but interpret policy against Microsoft guidance, not real-time login telemetry.
What does accountExpires zero mean?
Zero or specific sentinel integers mean the account never expires depending on schema and functional level. Decode suspicious max-int values here to distinguish never-expire sentinels from real future expiration instants before running disable scripts. The value 9223372036854775807 often signals never-expire in Windows Server schemas — confirm against your forest functional level documentation.
Can I convert a date to FILETIME for testing?
Yes. Enter a civil datetime to generate the corresponding FILETIME integer for LDIF fixtures or manual attribute edits in lab forests. Round-trip decode once and compare with PowerShell FromFileTime on the same jump host to validate lab procedures. Lab AD snapshots should never reuse production FILETIME integers — generate fresh values for each test user.
Does Azure AD use FILETIME in exports?
Cloud directory exports often emit ISO 8601 strings instead of raw FILETIME, while on-prem ldapsearch still shows integers. Know your export source — hybrid sync CSVs may mix formats. Use ISO converter for string dates and this page for raw AD integers.