When a Comment Has No Timestamp, What Does Recent Mean?
I went back to a date field while working on Social Relations Lab(소셜 릴레이션스 랩), an unfinished local experiment for keeping provenance and history of authorized social interactions so the human operator can decide what comes next.
The date we observe a comment does not necessarily tell us when somebody wrote it. Treating those dates as interchangeable could make an old comment discovered today look like a fresh inbound reply.
Two fields the source code already separates
On October 26, 2026, I inspected the current Mac-local Interaction model. It records occurredAt for the source-supported time of an event and observedAt for when the system observed it.
This is valuable for third-party public index records that lack reliable original comment timestamps. Their occurredAt value can remain null without silently manufacturing an authored date.
But the groupRelationships function sorts records using event time or, if missing, observation time. It then returns relationship-level firstAt and lastAt based only on the selected records’ event times. In the Contact 360 view those fields are used in labels for first and latest observation.
I wanted to see what that meant in a real function call before treating it as a user-facing defect.
A single synthetic event, actually executed
I ran the current TypeScript domain function read-only in Node.js. No real account, imported user records, code change or network connection was involved.
| Input or output | Observed result from the synthetic case |
|---|---|
| Event authored time, occurredAt | null |
| Event observation time, observedAt | 2026-10-26 12:00 UTC |
| Grouped relationship stage | observed |
| Relationship firstAt | empty string |
| Relationship lastAt | empty string |
| Observation timestamp on the event | still present |
The relationship exists and its original event retains the observation date. Yet the relationship-level dates are blank. A message that says ‘authored time unknown’ is accurate. A summary that says ‘first observation time unknown’ can be misleading when the system did observe the record at a known time.
This is one contract reproduction using wholly fictional input, not a report that every timestamp feature is broken or that any real customer was affected.
Why not fill the missing date automatically?
Because it would answer the wrong question.
| Question | Acceptable evidence | Unsupported inference |
|---|---|---|
| When was the comment written? | A native/source-backed event time | Treat observation as authored time |
| When did the system find it? | Ingestion or observation time | Claim it did not exist beforehand |
| Was there reciprocal dialogue? | Connected and attributable reply evidence | Treat one public observation as a verified response |
This matters in any small operator’s contact history. A late import of an old exchange is not a new voluntary customer message. A chart that presents both under the same time label could change which follow-up a person chooses.
The argument for keeping the interface simpler
Not every relationship card needs two clocks. The operator may care more about context and next steps than additional date fields. We could keep an explicit ‘original date unknown’ label and show the observation date only within the source-coverage detail panel.
That may be preferable to adding another timestamp widget. More data does not automatically improve comprehension.
The smallest useful test
I sent the Mac development owner a four-case synthetic evaluation proposal: known authored date with later observation, unknown authored date with known observation, an old record imported late, and observation-only source material.
Compare the current Contact 360 wording with a minimal distinction between authored and observation time. The intended success condition is that readers stop treating a newly observed old event as a fresh exchange while still recognizing when source evidence was actually collected.
No developer decision or usability experiment is complete, and this is not a shipped timeline change.
Earlier I wrote about what incoming comments can prove and why a clicked Post control is not a delivery receipt. This time I am asking what a known source can actually tell us about when an event happened.
Other developer notes and the Korean edition provide the rest of the series.
This diary is based on a read-only synthetic call to the current Mac domain function on October 26, 2026. It includes no real person’s messages and does not claim implemented fixes, verified user feedback or a public beta.