Use MxSortRows to sort on a "date" column?

AmiBroker
1

Hi

Is is safe to use MxSortRows to sort on a “date” column?

2

It depends what date format you are using (datenum() or datetime()).
DateNums are 100% fine because they are just numbers. DateTime is trickier
since they are packed bit fields.

3

Hello

I am using datetime() values only. Never used datenum().

So if my values are post 1964 is it safe to sort with MxSortRows?

And also is it safe to compare datetime() values with >, < etc operators if the values are 1964 and later?

4

You might want to re-read what @Tomasz said. Using DateTime is problematic because of the way it’s stored.

However, you can easily convert DateTime to DateNum using DateTimeConvert and then use the result of that to do the sort. https://www.amibroker.com/guide/afl/datetimeconvert.html

You can only reliably compare DateTimes with DateTimeDiff, as you’ll note from the caveats on the help page for it. https://www.amibroker.com/guide/afl/datetimediff.html

5

Hello HelixTrader

I had read the documentation. In this page ( https://www.amibroker.com/guide/afl/datetimediff.html ) it states:
“Any other comparisions (less than/greater then), using normal operators > < may sometimes lead to wrong results (if one of dates compared is pre-1964), therefore to compare two datetime numbers reliably you should use DateTimeDiff.”

Since I am not using that old dates, I was wondering if I could get away with normal operators on datetime() values.

I am trying to find a way to avoid converting to datenum + timenum and sorting on 2 fields.

Also, I don’t really care for sorting. All I want is group together Matrix lines with the same DateTimestamp.

6

Yes you can use MxSortRows() for datetimes after 1964. If you need dates earlier than that use datenums.

7

Great news!

So on the same logic, is it safe to compare datetime() values with >, < etc operators if the values are 1964 and later?

8

No, because relying on undocumented stuff when reliable and documented solution (DateTimeDiff) exists is VERY BAD idea. Your code may and will inevitably break when internal implementation changes a bit.

2 Likes
9

You are right. Thank you Tomasz.