Message timestamp (ts) precision about slackapi HOT 6 CLOSED

Hmmmm, so I ran into that issue originally and had hoped that ToProperTimeStamp would fix the underlying issue but that doesn't seem to be happening. Maybe they switched their internal version to a double or something, either way that's not really a maintainable way to implement this.

Unfortunately I'm not fond of the idea of switching a float to a string because if anyone is using it for something else, there'll be regressions.

Could you try seeing if the decimal type (in place of float) would help with your issue?

from slackapi.

Thanks. I was only suggesting a new property of type string to preserve the original timestamp, in addition to the existing DateTime ts prop. I guess not best practice; kinda dirty.

Already was using decimal type in the ToProperTimeStamp adjustments, otherwise not making any other changes elsewhere. Data retrieved from GetHistory isn't stored to db or anything, just immediately reused to send delete commands, without any type conversion except that which takes place already in the SlackAPI JSON deserialization on the way in, and then in ToProperTimeStamp on the way back out.

Will keep fiddling. Thanks!

from slackapi.

Hi, looks like my issue is now resolved.

What I did was to override the ToProperTimeStamp extension and change the line
string result = ((that.ToUniversalTime().Ticks - 621355968000000000m) / 10000000m).ToString("G17");

to:

string result = ((that.ToUniversalTime().Ticks - 621355968000000000m) / 10000000m).ToString("0.000000");

Everything is now working smoothly (at least in all the ways I use this library). My prior mention of a new error when changing the above is also resolved with the ToString format as above.

I am not very familiar with the standard numeric format strings, but in my case G17 was not working, resulting in only 5 decimal places, when Slack was expecting 6 (at least now). Not sure if 0.000000 is the most appropriate solution here.

thanks

from slackapi.

Neat. Would you mind making a quick pull request for that?

On Fri, Nov 18, 2016, 02:30 stpeteparadox [email protected] wrote:

Hi, looks like my issue is now resolved.

What I did was to override the ToProperTimeStamp extension and change the
line
string result = ((that.ToUniversalTime().Ticks - 621355968000000000m) /
10000000m).ToString("G17");

to:

string result = ((that.ToUniversalTime().Ticks - 621355968000000000m) /
10000000m).ToString("0.000000");

Everything is now working smoothly (at least in all the ways I use this
library). My prior mention of a new error when changing the above is also
resolved with the ToString format as above.

I am not very familiar with the standard numeric format strings, but in my
case G17 was not working, resulting in only 5 decimal places, when Slack
was expecting 6 (at least now). Not sure if 0.000000 is the most
appropriate solution here.

thanks

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#74 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0S9pAMscuT2wpUMhGMNAjdUvDX3pjNks5q_VQYgaJpZM4K2D3A
.

from slackapi.

Fixed with Nuget package 1.0.5.93

from slackapi.

I was about to post a separate issue about this, but luckily Github suggested this thread.

However, I agree with @stpeteparadox that it feels kinda strange to rewrite something that's meant to be a unique ID.

IMHO, the more correct way would be to preserve TS as a string and just have an extension method to extract the DateTime whenever that's needed for whatever reason one might have. (Or maybe just another property on the model, that has get returning TS as a DateTime).

Why try to change the API specification set by the developers you are building a library around?

From Stripe's documentation:

There are a few additional fields that describe the author (such as user or bot_id), but there's also an additional ts? field. The ts value is essentially the ID of the message, guaranteed unique within the context of a channel or conversation.

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.

The ts of a message can be used in many operations such as replying to it in a thread, or modifying the message. But it can also be used to retrieve the message by itself.

Additionally, the class SlackAPI.PostMessageResponse returns ts as a string, so I think there might be some kind of decision to made as to which direction to take?

Other than that - thank you for the great work. I might submit a pull request for a few things soon.

from slackapi.