What CFAbsoluteTime is
Apple’s Core Foundation measures time as CFAbsoluteTime, a floating-point count
of seconds from a single reference instant: midnight on 1 January 2001 in UTC.
This is the basis of NSDate and Swift’s Date, so the same value turns up
throughout macOS and iOS. Because the origin differs from the familiar Unix epoch,
the raw numbers are easy to misread; this tool converts them to ordinary dates and
back.
How it works
The whole conversion rests on one offset. The Apple reference date of 1 January 2001 is exactly 978,307,200 seconds after the Unix epoch of 1 January 1970. To turn a CFAbsoluteTime into a date the tool adds that offset to get a Unix timestamp, then builds a UTC date from it. Going the other way it computes the Unix seconds for the date and subtracts the offset.
662688000 -> 2022-01-01T00:00:00Z
0 -> 2001-01-01T00:00:00Z
2022-01-01T00:00:00Z -> 662688000
Example and notes
CFAbsoluteTime is defined in UTC, so the tool reads and writes UTC; convert local times before entering them. Values are floating point, so fractional seconds are allowed, and values before the 2001 reference date are simply negative. The result also shows the matching Unix timestamp, which makes it straightforward to line up Apple artifacts with logs and databases that use Unix time.
Where you will encounter CFAbsoluteTime
Digital forensics and DFIR is the most common context for needing to decode these values. macOS and iOS store timestamps in CFAbsoluteTime in numerous places:
- Safari browser history and download records (stored in Spotlight metadata and SQLite databases)
- iOS device backups (iTunes/Finder backups contain
.plistfiles with CFAbsoluteTime values throughout) - macOS
.plistfiles system-wide — preferences, cache, and sync databases all use this type - Spotlight metadata attributes such as
kMDItemFSContentChangeDateandkMDItemLastUsedDate - iOS forensic tools such as iMazing, Cellebrite, and GrayKey output CFAbsoluteTime values in their raw data export
App development is the other major use case. When debugging a Swift or Objective-C app and inspecting a Date value at a breakpoint, the LLDB debugger typically prints the underlying CFAbsoluteTime float rather than a human-readable date. This tool lets you quickly convert that debug value to a real date without writing extra code.
CFAbsoluteTime vs. other Apple timestamps
Apple uses more than one time representation internally, which can cause confusion:
| Format | Epoch | Notes |
|---|---|---|
| CFAbsoluteTime / NSDate | 2001-01-01 UTC | Used by most Cocoa APIs |
| Mac HFS+ dates | 1904-01-01 local | Used in legacy filesystem metadata |
| iOS CoreData dates | 2001-01-01 UTC | Same epoch as CFAbsoluteTime |
| APFS creation times | Unix epoch 1970 | Nanoseconds since 1970, APFS-native |
When you see a large number around 700,000,000 to 800,000,000 and suspect it is a date, it is almost certainly CFAbsoluteTime from the mid-2020s. If you see a very large number in the range of 16,000,000,000+, it is likely a nanosecond-resolution Unix timestamp.
Working backward from a date
To convert a known date to CFAbsoluteTime — for example, to construct a database query or filter range — enter the ISO 8601 UTC date in the tool and it computes the float directly. Knowing that 1 January 2026 at midnight UTC maps to roughly 788918400 lets you write targeted queries against Apple SQLite databases without relying on the platform’s date-parsing functions.