Every Timestamp Format Explained: Unix, LDAP, WebKit, Cocoa, and Why They All Start on Different Days

If you've ever pulled a timestamp from a database, an API response, or a log file and stared at a number like 133515360000000000 wondering what it means — you're not alone. There are at least 14 different timestamp formats in active use across computing, and they all count from different starting points using different units.

This guide explains every major timestamp format: what it is, which systems use it, what its epoch origin is, and how to recognize it by sight. By the end, you'll be able to glance at a number and know whether it's Unix seconds, LDAP, WebKit, or something else entirely.

The Unix Family

Unix Seconds (The Standard)

The most common timestamp format in computing. Counts the number of seconds since January 1, 1970 00:00:00 UTC — a moment known as the Unix epoch. Current values are 10 digits long (e.g., 1771387200). Used by Linux, macOS, most programming languages, most databases, most APIs, and most backend systems. When someone says "epoch time" or "timestamp" without qualification, they almost always mean this.

Unix Milliseconds

Same as Unix seconds but with millisecond precision. Multiplied by 1,000. Current values are 13 digits (e.g., 1771387200000). Used by JavaScript (Date.now()), Java (System.currentTimeMillis()), and many modern APIs that need sub-second precision.

Unix Microseconds and Nanoseconds

Unix microseconds (16 digits) and nanoseconds (19 digits) extend precision further. Microseconds are used by PostgreSQL's internal timestamp storage and some high-frequency trading systems. Nanoseconds are used by Go's time.UnixNano() and some scientific instrumentation.

Unix Hex

Some systems store Unix timestamps as hexadecimal values prefixed with 0x. For example, 0x65E4A080 equals 1,709,449,344 in decimal. You'll encounter these in firmware, embedded systems, and some network protocols.

The Microsoft/Windows Family

LDAP / Active Directory (FILETIME)

Counts 100-nanosecond intervals since January 1, 1601 00:00:00 UTC. Values are 18 digits long (e.g., 133515360000000000). Used throughout Microsoft's ecosystem: Active Directory user attributes (accountExpires, pwdLastSet, lastLogonTimestamp), Windows NTFS file metadata, Exchange Server, and any system built on Windows FILETIME.

Why 1601? Microsoft chose the start of a 400-year Gregorian calendar cycle. Every 400 years, the calendar repeats its pattern of leap years exactly. Starting from 1601 makes calendar arithmetic simpler — a practical engineering decision that has confused developers for decades.

WebKit / Chrome

Counts microseconds since January 1, 1601 00:00:00 UTC. Values are 17 digits (e.g., 13351536000000000). Used internally by Google Chrome for cookies, browsing history, and cached data. If you're doing forensic analysis of Chrome data or debugging cookie expiration, you'll encounter this format.

WebKit timestamps share the same epoch as LDAP (1601) but use microseconds instead of 100-nanosecond intervals, so the values are 10x smaller than LDAP for the same moment in time.

The Apple Family

Cocoa / Core Data

Counts seconds since January 1, 2001 00:00:00 UTC. Current values are 9 digits (e.g., 793540800). Used by Apple's NSDate class in Swift and Objective-C, Core Data framework, and throughout macOS and iOS application data. If you're debugging an Apple app or examining a .sqlite database from an iPhone backup, timestamps are likely in this format.

The Cocoa epoch (2001) was chosen because it's the year Mac OS X was released — Apple's fresh start after the classic Mac OS era.

Mac HFS+

Counts seconds since January 1, 1904 00:00:00 local time (not UTC). Used by the classic Mac OS HFS and HFS+ file systems for file creation and modification dates. Older Macs and older external drives formatted with HFS+ use this format. It's becoming less common as Apple transitions to APFS, but you'll still encounter it in legacy data.

The SAS Family

SAS (Statistical Analysis System) uses January 1, 1960 as its epoch. SAS timestamps come in two flavors: seconds since the epoch (for datetime values) and days since the epoch (for date-only values). If you work with SAS datasets, SPSS imports, or healthcare/pharmaceutical data, you'll encounter these regularly.

The Standards

ISO 8601

Not a numeric epoch but the international standard for representing dates and times as text: 2026-02-18T12:00:00Z. The T separates date from time. The Z indicates UTC (Zulu time). This is the format you should use when storing or transmitting timestamps as strings — it's unambiguous, sortable, and universally parsed.

RFC 2822 / RFC 3339

RFC 2822 is the email header date format: "Wed, 18 Feb 2026 12:00:00 +0000". RFC 3339 is essentially ISO 8601 with stricter rules, commonly used in internet protocols and APIs. Both are human-readable text formats rather than numeric epochs.

Quick Recognition Cheat Sheet

The next time you encounter a mystery number in a database or API response, count the digits and check this table. Or just paste it into Chronoshift — the auto-detection engine does this for you instantly.

Related Articles