slackhq / slack-api-docs

API Docs for Slack.com
https://api.slack.com/
426 stars 85 forks source link

Timestamp type inconsistency #7

Open mpickering opened 9 years ago

mpickering commented 9 years ago

In the documentation for the file object a timestamp is given as an integer

"timestamp" : 1356032811,

but in many other places, different timestamps are given as strings. For example in the specification of message.

"ts": "1355517523.000005"

Should these two values be treated the same or do they have different meanings?

ernesto-jimenez commented 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

mpickering commented 9 years ago

Do you know what the digits after the decimal point indicate? Are they just to ensure uniqueness?

paulhammond commented 9 years ago

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.

mpickering commented 9 years ago

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"
paulhammond commented 9 years ago

That is a bug. I'm talking to the team about it now!

paulhammond commented 9 years ago

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!

davclark commented 9 years ago

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.]

lchase commented 9 years ago

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.

Fabszn commented 9 years ago

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

ichthyos commented 7 years ago

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.

ken9ross commented 6 years ago

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?

Galvin-wjw commented 6 years ago

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)

namedgraph commented 5 years ago

@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.

JobinBiju commented 2 years ago

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.

starball5 commented 1 year ago

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).