Epoch Time Converter LDAP: How to Convert

An LDAP timestamp is a 64-bit integer counting 100-nanosecond intervals since January 1, 1601 (UTC), and this converter turns that number into a human-readable date and time, or converts a date back into the LDAP format. You enter either the 18-digit LDAP value or a calendar date, and the tool instantly shows the equivalent in both LDAP and standard Unix epoch time. This page explains the conversion formula, gives a worked example, and covers common pitfalls when working with Active Directory and other LDAP directories.

Formula

The LDAP timestamp format is defined by the Active Directory and other LDAP-compliant directories as the number of 100-nanosecond intervals since January 1, 1601, 00:00:00 UTC. The Unix epoch, in contrast, counts seconds since January 1, 1970, 00:00:00 UTC.

The conversion formula is:

Unix time (seconds) = (LDAP timestamp / 10,000,000) - 11,644,473,600

Where:

• LDAP timestamp – the 64-bit integer value (e.g., 133000000000000000)
• 10,000,000 – the number of 100-nanosecond intervals in one second
• 11,644,473,600 – the number of seconds between 1601-01-01 and 1970-01-01

To convert back from Unix time to LDAP, reverse the operation:

LDAP timestamp = (Unix time + 11,644,473,600) × 10,000,000

Worked Example

Using the default value from the calculator: 133,000,000,000,000,000

1. Divide by 10,000,000: 133,000,000,000,000,000 ÷ 10,000,000 = 13,300,000,000 seconds
2. Subtract the epoch offset: 13,300,000,000 - 11,644,473,600 = 1,655,526,400 seconds
3. Convert to a date: 1,655,526,400 seconds after 1970-01-01 is June 15, 2022, 12:26:40 UTC (check with a standard Unix converter).

The calculator shows the same result: the first output is the Unix timestamp (1655526400), and the second output shows the corresponding UTC date and time.

Why LDAP Uses 1601 as the Epoch

The choice of January 1, 1601 is not arbitrary. The Gregorian calendar was designed to have a 400-year cycle, and 1601 is the start of the fourth 400-year cycle after the calendar’s introduction in 1582. Microsoft chose this date for Active Directory to align with the Gregorian calendar’s leap-year rules, making date arithmetic simpler and more accurate over long periods.

This 64-bit integer can represent dates from the year 1601 up to the year 30828, which is far beyond any practical need. In contrast, the Unix 32-bit timestamp overflows in 2038, which is why many systems are migrating to 64-bit time.

How to Read an LDAP Timestamp

When you see a number like 133000000000000000, it looks intimidating, but it’s just a count of tiny time intervals. To get a rough idea of the date without a calculator, you can divide by 10 million to get seconds, then subtract the 1601-to-1970 offset. A quick mental trick: if the LDAP value is around 13,000,000,000,000,000, it’s roughly the year 2022. Each increase of about 3.16×10¹⁴ in the LDAP value corresponds to one year.

Most LDAP directories store timestamps in UTC, so the result is always in UTC. If you need a local time zone, you must apply the appropriate offset manually, as the converter does not adjust for time zones.

Common Mistakes When Converting LDAP Time

• Forgetting the offset – Dividing by 10,000,000 gives you seconds since 1601, not since 1970. You must subtract 11,644,473,600.
• Using milliseconds instead of 100-nanosecond intervals – Some systems use milliseconds, which would give a completely different result. Always confirm the unit.
• Mixing up endianness – LDAP timestamps are stored as 64-bit big-endian integers. If you read the bytes in the wrong order, the value will be nonsense.
• Ignoring the sign – Negative LDAP timestamps represent dates before 1601, which are rare but possible. The formula still works, but the result will be a negative Unix timestamp.

When to Use an LDAP Epoch Converter

You’ll need this conversion when:

• You are debugging an Active Directory attribute like whenCreated, whenChanged, or lastLogonTimestamp and want to see the actual date.
• You are writing a script or query that needs to compare LDAP dates with current time in Unix format.
• You are migrating data from an LDAP directory to a system that uses Unix time.
• You are analyzing security logs that display LDAP timestamps.

Many directory tools, like ldapsearch, output raw 64-bit integers. Without a converter, it’s nearly impossible to tell when an account was created just by looking at the number.

Alternatives to a Manual Converter

Besides online calculators, you can convert LDAP timestamps using:

• PowerShell – Use [DateTime]::FromFileTime($ldapValue) to get a .NET DateTime object.
• Python – Use datetime.datetime(1601,1,1) + datetime.timedelta(microseconds=ldap_value/10).
• Excel – Divide the LDAP value by 10,000,000, subtract 11644473600, then divide by 86400 and add 25569 to get a serial date.
• Command line – On Linux, use date -d @$(( (ldap_value / 10000000) - 11644473600 )).

These methods are useful when you need to process many values or integrate the conversion into a script.

Frequently Asked Questions

What is the difference between LDAP timestamp and Unix timestamp?

LDAP timestamps count 100-nanosecond intervals since January 1, 1601, while Unix timestamps count seconds since January 1, 1970. The LDAP format is used primarily in Microsoft Active Directory, while Unix time is common in Linux and many programming languages.

Why does my LDAP timestamp have 18 digits?

Because it represents a very large number of 100-nanosecond intervals. Even a date in 2020 is about 1.3×10¹⁷ intervals, which is 18 digits. The 64-bit integer can hold up to about 1.8×10¹⁹, so 18 digits is normal.

Can I convert an LDAP timestamp to a local time zone?

Yes, but the converter only gives UTC. To get local time, you need to apply your time zone offset. For example, if you are in Eastern Daylight Time (UTC-4), subtract 4 hours from the UTC result. Some tools automatically convert to local time, but this calculator does not.

What happens if I enter a negative LDAP timestamp?

Negative values represent dates before 1601. The formula still works: divide by 10,000,000 and subtract the offset, which will give a negative Unix timestamp. For example, -10000000 would be 1600-12-31 23:59:59 UTC. Such values are rare and usually indicate a misconfigured system.

Is the LDAP timestamp the same as the Windows FILETIME?

Yes, the format is identical. Windows FILETIME also counts 100-nanosecond intervals since 1601. This means you can use the same conversion for both LDAP attributes and Windows file timestamps.

Why does my converter show a different date than my LDAP browser?

Your LDAP browser might already convert the value to local time or display it in a different format. Always check whether the tool is showing UTC or local time. Also, ensure you are not accidentally interpreting the value as milliseconds or microseconds.

Related

• Adidas Originals vs Other Brands for Band Merch
• Start Vlogging: A Practical Guide to Your First Video
• DTS-HD Master Audio: What It Is and How Playback Works

in ldap | LDAP timestamp | - | 133000000000000000 | 0
out unix | Unix epoch (seconds) | s | (ldap / 10000000) - 11644473600 | 0
out date | UTC date & time | - | (ldap / 10000000 - 11644473600) | 0