Store chat.db timestamps as `Int64` instead of `Date`. by pmanot · Pull Request #91 · beeper/platform-imessage

pmanot · 2026-05-29T15:08:17Z

No description provided.

indent · 2026-05-29T15:08:22Z

PR Summary

Keeps iMessage message.date / message.date_read as raw Int64 nanoseconds end-to-end so DB follow-up queries (e.g. the before/after cursors used by findClosestSelectablePart) no longer round-trip through Date → Double → Int and lose precision/range. Pure refactor with no DB schema, wire-format, or external behavior changes intended.

Message gains stored dateNanosecondsSinceReferenceDate / dateReadNanosecondsSinceReferenceDate: Int64?; date / dateRead become computed Date? views (no longer settable; memberwise init labels changed).
MessageQueryFilter.before(_:) / .after(_:) switched from Date to nanosecondsSinceReferenceDate: Int64; updated callers in IMDatabase+Closest.swift and IMDatabaseTestBench/ArgumentParsing.swift.
New Column.imCoreDateNanoseconds() -> Int64? helper; the "reject distant-future bogus dates" guard moves into a new failable Date.init?(imCoreNanosecondsSinceReferenceDate: Int64) used by both imCoreDate() and the Message.date computed accessor.

Issues

1 potential issue found:

findClosestSelectablePart no longer bails on bogus parent-message dates: the guard moved from message.date (nil for <=0 and >= .distantFuture) to message.dateNanosecondsSinceReferenceDate (nil only for <=0), so a clamped/garbage future date now runs messages(filter: .before(HUGE)) over the whole chat and picks an arbitrary "closest" part instead of returning nil. → Autofix

CI Checks

Waiting for CI checks...

indent · 2026-05-29T15:12:05Z

        }

-        guard let targetDate = message.date else {
+        guard let targetDateNanoseconds = message.dateNanosecondsSinceReferenceDate else {


Bogus-date short-circuit weakened: Previously this guard used message.date, which was nil both for date <= 0 and for values that mapped past .distantFuture (the defensive clamp added in Column+.imCoreDate). After this PR, message.dateNanosecondsSinceReferenceDate is only nil for date <= 0 — the distant-future check now lives on the computed Message.date accessor and never gates this code path.

Concrete consequence: if a parent message has a malformed/extreme date value (the case the comment calls 'rare/impossible'), this function previously logged target's parent message has no date and returned nil. Now it issues messages(in: chat, filter: .before(nanosecondsSinceReferenceDate: HUGE), ...) (returns the most recent N messages — unrelated to the target) and .after(...) (returns nothing), then happily picks an arbitrary 'closest' selectable part anchored to garbage.

Probably unreachable today, but it removes the defensive behavior the comment relies on. Consider either guarding on message.date != nil here, or letting imCoreDateNanoseconds() apply the same distant-future rejection so the raw field stays in sync with the computed one.

coderabbitai · 2026-05-29T15:14:13Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4de6d261-5e4a-4de3-a516-d0f7808772d4

📥 Commits

Reviewing files that changed from the base of the PR and between 7f4852e and 4bd83cd.

📒 Files selected for processing (6)

src/IMessage/Sources/IMDatabase/Database/IMDatabase+Closest.swift
src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift
src/IMessage/Sources/IMDatabase/Models/Message.swift
src/IMessage/Sources/IMDatabase/Support/Column+.swift
src/IMessage/Sources/IMDatabase/Support/Date+NanosecondsApple.swift
src/IMessage/Sources/IMDatabaseTestBench/ArgumentParsing.swift

📜 Recent review details

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2026-05-03T17:00:19.662Z

Learnt from: KishanBagaria
Repo: beeper/platform-imessage PR: 69
File: src/IMessage/Sources/IMessage/EventWatcher/EventWatcher+Updates.swift:89-93
Timestamp: 2026-05-03T17:00:19.662Z
Learning: In the beeper/platform-imessage Swift codebase, keep message IDs (`PlatformSDK.MessageID`) as raw GUIDs. When mapping from DB/event rows to `message.id`, set the ID directly from `msgRow.guid` (no GUID→public-ID hashing or transformation). For multi-part messages, append the part index as `_<part.index>` to the GUID-derived ID. During code review, if changes touch message ID creation/mapping, ensure this raw GUID + optional `_<part.index>` suffix behavior is preserved.

Applied to files:

src/IMessage/Sources/IMDatabase/Models/Message.swift
src/IMessage/Sources/IMDatabase/Support/Column+.swift
src/IMessage/Sources/IMDatabase/Support/Date+NanosecondsApple.swift
src/IMessage/Sources/IMDatabaseTestBench/ArgumentParsing.swift
src/IMessage/Sources/IMDatabase/Database/IMDatabase+Closest.swift
src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift

🪛 SwiftLint (0.63.2)

src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift

[Warning] 100-100: Magic numbers should be replaced by named constants

(no_magic_numbers)

[Warning] 101-101: Magic numbers should be replaced by named constants

(no_magic_numbers)

🔇 Additional comments (8)

src/IMessage/Sources/IMDatabase/Database/IMDatabase+Closest.swift (2)

81-85: Previously reported defensive date validation regression remains.

This is the same issue already identified earlier: guarding on raw nanoseconds here can bypass the existing bogus-date protection that previously relied on the computed Date.

116-120: LGTM!

Also applies to: 129-133

src/IMessage/Sources/IMDatabaseTestBench/ArgumentParsing.swift (1)

43-47: LGTM!

src/IMessage/Sources/IMDatabase/Support/Date+NanosecondsApple.swift (1)

26-35: LGTM!

src/IMessage/Sources/IMDatabase/Support/Column+.swift (1)

25-25: LGTM!

src/IMessage/Sources/IMDatabase/Models/Message.swift (1)

21-32: LGTM!

src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift (2)

23-29: LGTM!

100-101: LGTM!

Also applies to: 117-118

📝 Walkthrough

Summary by CodeRabbit

Refactor
- Enhanced internal timestamp handling mechanisms for improved data accuracy and query performance.

Walkthrough

This PR migrates message timestamp handling from Date objects to nanosecond-based Int64 storage and querying. The refactoring introduces a new Date initializer for nanosecond conversion, updates the Message model to store raw nanoseconds and compute Date properties from them, revises query filters to accept nanoseconds instead of Date, and updates all call sites accordingly.

Changes

Message timestamp storage and querying migration

Layer / File(s)	Summary
Date nanosecond conversion utilities `src/IMessage/Sources/IMDatabase/Support/Date+NanosecondsApple.swift`, `src/IMessage/Sources/IMDatabase/Support/Column+.swift`	A new failable `Date` initializer `init?(imCoreNanosecondsSinceReferenceDate:)` validates nanosecond-to-date conversions and returns `nil` for overflow values. The `imCoreDate()` helper simplifies to use this new initializer, removing explicit `.distantFuture` checks.
Message model: nanosecond storage with computed Date properties `src/IMessage/Sources/IMDatabase/Models/Message.swift`	`Message` adds raw nanosecond properties `dateNanosecondsSinceReferenceDate` and `dateReadNanosecondsSinceReferenceDate` sourced from `chat.db`, and converts `date` and `dateRead` from stored properties to computed getters derived via the new nanosecond initializer.
MessageQueryFilter API: nanosecond-based before/after `src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift`	`MessageQueryFilter.before()` and `.after()` are redefined to accept `nanosecondsSinceReferenceDate: Int64` instead of `Date`, and emit SQL predicates that compare the `date` column as integers.
Message row initialization: nanosecond extraction and assignment `src/IMessage/Sources/IMDatabase/Database/IMDatabase+Messages.swift`	The `Message` row initializer extracts nanoseconds from database columns 9 and 10 via `imCoreDateNanoseconds()` and passes them to the new raw nanosecond properties.
Query call sites: updated filter API usage `src/IMessage/Sources/IMDatabase/Database/IMDatabase+Closest.swift`, `src/IMessage/Sources/IMDatabaseTestBench/ArgumentParsing.swift`	`findClosestSelectablePart` retrieves the target message's nanosecond timestamp and uses it in `.before()` and `.after()` filters. `ArgumentParsing` converts parsed `Date` values to nanoseconds before creating filters.

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	No pull request description was provided by the author; the description field is empty.	Add a description explaining the motivation, benefits, and any breaking changes or migration considerations for storing timestamps as Int64 instead of Date.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title clearly and concisely summarizes the main change: storing chat.db timestamps as Int64 instead of Date, which aligns with all the modifications across multiple files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch purav/raw-message-dates

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

keep message dates raw

4bd83cd

indent Bot reviewed May 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Store chat.db timestamps as `Int64` instead of `Date`.#91

Store chat.db timestamps as `Int64` instead of `Date`.#91
pmanot wants to merge 1 commit into
mainfrom
purav/raw-message-dates

pmanot commented May 29, 2026

Uh oh!

indent Bot commented May 29, 2026 •

edited

Loading

Uh oh!

indent Bot May 29, 2026

Uh oh!

coderabbitai Bot commented May 29, 2026 •

edited

Loading

Summary by CodeRabbit

Walkthrough

Changes

❌ Failed checks (1 warning, 1 inconclusive)

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

1 participant

Conversation

pmanot commented May 29, 2026

Uh oh!

indent Bot commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

indent Bot May 29, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Walkthrough

Changes

❌ Failed checks (1 warning, 1 inconclusive)

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

1 participant

indent Bot commented May 29, 2026 •

edited

Loading

coderabbitai Bot commented May 29, 2026 •

edited

Loading