Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nanoseconds are not sorted correctly #7687

Closed
3 tasks done
webbiscuit opened this issue Jan 19, 2024 · 2 comments
Closed
3 tasks done

Nanoseconds are not sorted correctly #7687

webbiscuit opened this issue Jan 19, 2024 · 2 comments
Assignees
Labels
💡 feature request New feature or request ✅ merged A fix for this issue has been merged
Milestone

Comments

@webbiscuit
Copy link

Preflight Checklist

Storage Explorer Version

1.32.1

Regression From

No response

Architecture

x64

Storage Explorer Build Number

20231114.10

Platform

macOS

OS Version

macOs 14.2.1

Bug Description

Datetimes are not sorted correctly at the nanosecond level:
image
The screenshot is a sort from latest to oldest times. The top 3 times are in the wrong order. It looks like nanoseconds are being ignored in the sorting.

Steps to Reproduce

Launch Storage Explorer
Find a table with timestamps close together
Click the column to sort ascending/descending
See the timestamps out of order

Actual Experience

Launch Storage Explorer
Find a table with timestamps close together
Click the column to sort ascending/descending
Timestamps are out of order

Expected Experience

Launch Storage Explorer
Find a table with timestamps close together
Click the column to sort ascending/descending
Timestamps are in order

Additional Context

No response

@craxal
Copy link
Contributor

craxal commented Jan 19, 2024

The problem with timestamps is that they are converted to JavaScript Date objects for sorting. Date objects only have millisecond precision. Hence why timestamps that differ by a few nanoseconds may be sorted in the wrong order.

However, it's possible we can get away with string comparisons to get around the precision issue. The strings themselves are ISO Zulu strings, so we shouldn't have to worry about number/letter comparisons messing the order up.

@craxal craxal added ⚙️ tables Related to table storage and removed ⚙️ tables Related to table storage labels Jan 19, 2024
@MRayermannMSFT MRayermannMSFT added 💡 feature request New feature or request ❔ investigate We need to look into this further labels Jan 22, 2024
@MRayermannMSFT MRayermannMSFT added this to the 1.34.0 milestone Jan 22, 2024
@MRayermannMSFT MRayermannMSFT removed the ❔ investigate We need to look into this further label Feb 22, 2024
@craxal
Copy link
Contributor

craxal commented Mar 5, 2024

String comparisons are a bit risky, as it's difficult to predict how locales will order certain characters.

The Temporal API provides the necessary nanosecond precision and works beautifully, but comparing Temporal objects is very slow compared to Date objects.

I think the optimal solution here is to use a combination of the two. Since it's less likely for DateTime values to differ by less than a millisecond, we can take advantage of the faster comparison of Date objects. If the Date objects are the same, only then will we parse and compare the values as Temporal objects.

@craxal craxal added the ✅ merged A fix for this issue has been merged label Apr 16, 2024
@craxal craxal closed this as completed Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 feature request New feature or request ✅ merged A fix for this issue has been merged
Projects
None yet
Development

No branches or pull requests

3 participants