Open mpickering opened 9 years ago
I believe ts
is a per-channel unique timestamp and it's used to identify message events. see https://api.slack.com/events/message
Do you know what the digits after the decimal point indicate? Are they just to ensure uniqueness?
Thanks for asking about this! In general there are two different things called "timestamps" in our API:
The first are properties that are unix timestamps, usually indicating when something was created or updated, usually called "created" or "edited". These should all be integers (although it's possible, despite checking several times recently, that we've missed one).
The second are the message timestamps, which always use the "ts" name (eg: "ts", "event_ts"). These are returned as strings. Even though they look like floats, they should always be stored and compared as strings - because floats occasionally lose precision and that would be bad here.
The bit after the decimal point is a sequence that guarantees uniqueness and ordering:
Knowing all that, it becomes clear that the "timestamp" property on files is badly named. We've just introduced a new "created" property that better describes what it is, which will be returned by our APIs from today onwards. We'll maintain backwards compatibility by supporting the old "timestamp" property too.
I'm going to leave this issue open, because I'd like to get all of this documented in our docs, and not just on a github issue.
Thank you for the detailed reply. I just noticed on the response to rtm.start
that in team
the limit_ts
has a format which corresponds to neither of these schemes. Is this a bug? I infact decided to store these type stamps as a pair of integers (seconds since epoch and unique identifier) so this caused the parse to fail.
"limit_ts":"1414771324000055"
That is a bug. I'm talking to the team about it now!
And it's fixed, by removing that property entirely - it only appeared for some teams, but shouldn't have been there at all. Thanks for pointing it out!
To clarify the above, if a timestamp from one group (before the decimal) is smaller than the timestamp from another - can I assume that means it came before? Even better, can I reliably map these to (approximate) real-world times?
[edit: given recent activity, I'd like to point out that @paulhammond says the timestamps are unix (i.e., posix) times above.]
When was this fixed? Did it only apply to certain APIs? I am querying groups.history and the response doesn't include a created for the returned messages, still just ts.
Hello, Is it planned to add onto event type :message, new property 'created' with the date and time when the message has been created ?
Regards
Paul's reply above was very helpful -- thanks very much.
Just wanted to note that the documentation for the oldest
and latest
args to channels.history
might need to be updated to specify integers rather than floats.
I have filed feedback with Slack on a related issue for the behavior of the channels.history
method, and will follow up to request the docs be updated if those args are supposed to be integers.
Do I understand correctly that to uniquely identify a message we need: team(aka workspace)_id.channel_id.message_ts?
Is it anticipated that adding Enterprise Grid will add an additional prefix to that or will team_id remain globally unique?
If I use Webhook to send msgs to a channel, how can I get the message timestamp? And I am not the admin of the workspace , Can I delete the Webhook messages?(I create the webhook plugin)
@paulhammond so where is that created
property? I don't see it anywhere in the documentation:
https://api.slack.com/messaging/retrieving
I think it's quite unheard of for a serious web API not to provide metadata such as created
/modified
in the response payload. Not being able to retrieve message timeline makes it pretty much useless.
The timestamp in file upload is still inconsistent. Now it is returning an integer timestamp. Expected is a float in string format. I need to pass this timestamp to reactions.add api. Please tell a workaround or fix this.
Related on Stack Overflow: What is the meaning of the parts of a Slack API timestamp when it has a dot in it? (I wrote up some of the info here as a Q&A pair since someone posted a non-answer in another question asking about it).
In the documentation for the file object a timestamp is given as an integer
but in many other places, different timestamps are given as strings. For example in the specification of
message
.Should these two values be treated the same or do they have different meanings?