Cocoa / Mac Absolute Time

Cocoa timestamps, also called Mac Absolute Time, count seconds since January 1, 2001 UTC. Apple's frameworks use this reference throughout macOS and iOS, so the format appears in Core Data stores, property list files, Safari history, and countless application databases. Paste a Cocoa value here to see the date it represents, or pick a calendar date to convert the other way.

Why 2001

When Apple designed the modern Foundation date types, it chose a reference date near the start of the century rather than reusing the Unix epoch. The practical effect is that values for contemporary dates stay comparatively small, and dates before 2001 are represented as negative numbers rather than requiring a separate convention. The choice is arbitrary in the same way every epoch is arbitrary; what matters is knowing which one a given number uses.

The conversion

Add 978,307,200 to a Cocoa timestamp to get Unix seconds, then format normally. Subtract the same constant to convert a Unix timestamp into Cocoa time. That constant is the number of seconds between 1970 and 2001, including the leap days in between.

Cocoa values are frequently fractional, because the underlying type is a floating-point number of seconds rather than an integer. A value with a long decimal tail is normal and carries sub-second precision. This converter accepts fractional input and preserves the resulting instant, though it displays the date to the second for readability.

Where you will find these values

Core Data uses Cocoa time for every date attribute, so any application built on that framework stores its dates this way in the underlying SQLite file. Property lists written by system services and applications use it for timestamps. Safari's history and download records use it. Notes, Messages metadata, calendar caches, and many third-party apps follow the same convention because they simply persist the framework's native date type.

When you open one of those databases with a generic SQLite browser, dates appear as numbers in the seven-hundred-million to eight-hundred-million range for recent years. That magnitude is the giveaway: it is far too small to be a Unix timestamp for a modern date, and far too large to be anything else plausible.

Reference date versus time interval

Apple's frameworks distinguish between a point in time and a duration, and both are expressed as the same underlying floating-point seconds type. A value that looks like a Cocoa timestamp may in fact be an interval — a cache lifetime, a playback position, an animation duration — rather than an absolute instant. Magnitude usually resolves the question, since an interval is typically small while a timestamp for a recent date is in the hundreds of millions, but a stored zero is genuinely ambiguous between the epoch itself and an empty duration.

Check the column name and the surrounding schema before converting. Running an interval through a date converter produces a date in early 2001, which is a useful warning sign: a database full of dates clustered in the first days of that year almost certainly contains durations that were misread as instants.

Telling formats apart

A Unix timestamp for a recent date has ten digits and starts with a one or a two. A Cocoa timestamp for the same instant has nine digits. If you convert a value and land roughly thirty-one years too early, you treated Cocoa time as Unix time; if you land thirty-one years too late, you did the reverse. That fixed offset makes the mistake easy to recognize and easy to correct.

Some Apple contexts use nanoseconds since 1970 instead, particularly low-level file system metadata. Those values have nineteen digits and belong to a different conversion entirely. Check the magnitude before assuming which format you have.

Negative values are valid

Because the epoch sits in 2001, any date before that is stored as a negative number. A birth date, a scanned document, or an imported archive record can legitimately produce a negative Cocoa timestamp, and this converter handles them. Code that validates timestamps by rejecting negatives will corrupt exactly those records, which is a common and easily avoided bug when migrating data out of an Apple application.

Time zones

Cocoa timestamps are absolute instants measured in UTC. The calendar and locale layers of the framework apply a time zone only when formatting a date for display, which means the stored number carries no zone information at all. When comparing values across devices or correlating them with server logs, no adjustment is needed. Convert to local time once, at the point where a person reads the result, using the time zone converter if the target zone is not your own.

Practical uses

Developers migrating data out of a Core Data store need to translate every date column, and getting the epoch wrong shifts an entire dataset by three decades. Support engineers reading crash reports and diagnostic logs meet these values regularly. Investigators examining device backups rely on them to build timelines. Anyone writing a script against an Apple application's SQLite file needs the constant at hand.

Related converters

For Chromium browser databases, use the WebKit timestamp converter, which counts microseconds from 1601. Windows systems use the FILETIME format, and directory services use LDAP timestamps. Ordinary epoch values belong on the Unix timestamp converter, with a batch mode for lists. Spreadsheet serial numbers are handled by the Excel date converter. Everything is collected on the converters hub.

Verifying your work

Convert a value you can check independently — a file you know you created, a message you can date from memory, or a record with a visible date elsewhere in the application. If it lands correctly, the rest of the column will too. Round-tripping is the other quick test: convert a date to Cocoa time and back, and confirm you get the same instant. A mismatch of exactly 978,307,200 seconds means the epoch constant was applied in the wrong direction.