search

stoiveyp / Slack.NetStandard

.NET Core package that helps with Slack interactions
MIT License
41 stars 16 forks source link

Should Timestamp's "identifier" be numeric instead of a string? #43

Closed ProductiveRage closed 3 years ago

ProductiveRage commented 3 years ago

I think that the second component in a Slack Timestamp (eg. "1482960137.003543") will always be numeric and so we could parse it as an int or long instead of a string (potentially a nullable one if there are cases where a Timestamp is instantiated with no identifier - I noticed that the "identifier" constructor argument is optional and defaults to a null string).

It would be really helpful to me because I'm trying to import the data into an existing format that uses a DateTime and I want to be able to sort messages correctly that were written within the same second!

The official docs about messages says that:

They look like UNIX/epoch timestamps, hence ts, with specified milliseconds. They'll even sort like the same. But they're message IDs, even if they're partially composed in seconds-since-the-epoch.

.. which suggests that the second part will always be numeric.

I've also found a GitHub issue that was commented on by someone who used to work at Slack that says:

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

.. which also suggests that the second part will always be numeric.

Unfortunately, I can't find any definitive source of information that guarantees it!

What do you think?

(For now, I'm handling this on my end by trying to parse the identifier by prepending a "0." and ensuring that it parses as a double and its value is between 0 and 1 so that I can add that many partial seconds to the time derived from the EpochSeconds value).

stoiveyp commented 3 years ago

Hi @ProductiveRage. Currently not looking to move away from identifier being a string - primarily as that's Slack's guidance, and I do try and stick to that guidance when it exists; ignored it on other platforms where the properties seemed numeric and have paid a price for it later on.

If the guidance or documentation changes in the future I'm happy to re-visit

ProductiveRage commented 3 years ago

Understood! It feels tantalisingly close to be guaranteed but there just isn't that official definitive reassurance, so I understand your decision entirely. Thanks, though!