Message timestamps lose sender time zone context after profile changes
0 reputation · 24 Sept 2022, 23:07 UTC
0 reputation · 24 Sept 2022, 23:07 UTC
Slack stores every message timestamp as a UTC Unix epoch value and renders it in each viewer's current time zone setting. The sender's local time zone at the moment of sending is not persisted with the message, so historical messages cannot be displayed in the sender's original local time once either party updates their time zone preference.
The users.info API returns only the current tz (IANA identifier) and tz_offset (seconds from UTC) for a user. There is no field capturing the time zone that was in effect when a specific message was sent, and the tz_offset value does not reflect future daylight-saving transitions.
Determine whether a workspace can reconstruct the sender's local clock time for any historical message without relying on external logs or manual annotation.
Can the sender's original time zone be inferred from any combination of message metadata, user profile history, or audit logs? Does the Enterprise Grid audit log or any SCIM provisioning record retain historical time zone assignments per user? Is there a supported API or export format that includes the effective tz value at message creation time?
35775 reputation · 25 Sept 2022, 06:47 UTC
Slack records each message as a UTC Unix epoch value and displays it in the viewer’s current time zone. The sender’s local time zone at send time is not stored with the message, so historical timestamps cannot reflect the original zone once a user updates their preference.
Slack does not capture the sender’s time zone at the moment of message creation; it only retains the UTC timestamp.
The users.info API returns only the current IANA tz identifier and its UTC offset tz_offset at query time, which reflects the user’s offset at the moment of the request, not at message creation. Enterprise Grid audit logs record when a user changes their time zone, but they do not link those changes to individual messages. No documented Slack API or export includes a field such as sent_at_tz that stores the effective time zone at message authorship.
chat.history or conversations.history to retrieve a sample message payload and inspect it for any time zone attribute present at creation.tz change events occurring around the message timestamp to see if the effective offset can be correlated.users.info response matches the offset stored in the audit log for the relevant period.Based on the available data, a workspace cannot reliably reconstruct the sender’s original local clock time for any historical Slack message without external logging or manual annotation.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 25 Sept 2022, 09:01 UTC
Slack stores ts as a UTC Unix epoch and does not attach the sender's time zone to the message object. Because users.info returns only the current tz and tz_offset, applying that value to older messages works only if the sender's IANA zone never changed and no DST boundary falls between the message and now. After a profile change, the original local clock time cannot be recovered from Slack-native message metadata alone.
Practical check: call users.info before and after a known time-zone update, then open a historical message from the workspace export and confirm the JSON contains ts and user but no sender-time-zone field. Enterprise Grid audit or SCIM records may log the preference change, but they are not a per-message snapshot and should be verified against your admin console.