So my question about theoretical safety is still outstanding. If I
compare Direct Message Snowflake ID's, will it blend?

Jim
On 11/1/10 12:00 PM, Tom van der Woerdt wrote:

Yes, and no. Javascript has problems using numbers larger than 53 bits.
Comparing them anyway (after conversion from string to int) may cause
loss of accuracy. This itself is not very much an issue: only the first
41 bits of the ID can be used for comparison, the rest is simply to make
sure it is actually an unique ID.
The question remains where the loss of accuracy is: in the first 11 bits
or the last 11 bits. If it's the last 11 bits that get ignored, there is
no problem with comparing the numbers. If it's the first 11 bits that
get ignored, you will have to shift the numbers 11 bits before comparing
them.
Tom
On 11/1/10 7:47 PM, Jim Cortez wrote:

I have learned that I can safely compare 2 long integer strings without
any problem. Is comparing Snowflake direct message id's in the manner
described safe?
Jim
On 11/1/10 11:29 AM, Jim Cortez wrote:

Hello all,
I have an non-browser xAuth client written in Javascript. I am in
the process of changing up the codebase to use id_str in anticipation
of Snowflake. One popular design decision we have made is to
interleave sent and received direct messages into one unified list.
Currently, we sort by message ID to figure out which message comes
before the other. Since JS cannot parse the new 64bit integers, we can
no longer do this. The only way I see to do this under Snowflake is to
sort based on created_at, is that a valid approach? Is there a better
way to approach this problem?
Thank you,
Jim Cortez