Date Parsing not working correctly

[samsong]

I suggest changing date parse to this modified version below.
I have tested this and it works every time in my testing.
Just test the date as a numeric string

var parseDate = function(date) {
   date = date.replace(/\-/g, '/');
   date = date.replace(/(\d{1,2})[\/\-\.](\d{1,2})[\/\-\.](\d{2})/, '$1/$2/$3'); // format before getTime

   if(date.search(/\d{1,2}[\/\-\.]\d{1,2}[\/\-\.]\d{2,4}/) !== -1)
   {
     var date_parts = date.split(/\-|\.|\//);
     return '' + ("00"+date_parts[2]).substr(-2,2) + '' + ("00"+date_parts[1]).substr(-2,2) + '' + ("00"+date_parts[0]).substr(-2,2);
   }

   return new Date(date).getTime() || -1;
 };

[tristen]

@samsong if you could: cite what isn't working correctly, turn this into a pull request that includes a test that addresses what the previous code couldn't do, I'd be happy to include the change!

[samsong]

Hey man. Great library overall. Can you please test these dates on your system you will see the problem.

format: dd.mm.yyyy
format: dd.mm.yy
(date separator is a dot in some region)

The sorting completely stops / produces incorrect results.

Just try it with a few dates you'll see straight away.
I'm not 100% sure if the approach I've suggested will work in 100% of scenarios.

But for all that I can think of using a string comparison or even numeric comparison on (YYYYMMDD) should give the correct result.

FYI the code i've provided is targetting 2 digit year format so the code would need to be updated to work with both 2 digit & 4 digit.

ALTERNATIVELY, I would be interested if you could suggest why the original date parse method wasn't working with dot separator (even though I added dot handling into your code)

[FlashJunior]

i used the "data-sort" attribut as workaround.

Example:
instead of
<td>10.12.2018</td>

i used
<td data-sort="181210">10.12.2018</td>

a few days later it paid off, because I used a different formatting
<td data-sort="181210"><a href="...">Mo. 10.12.18</a></td> and it worked perfect

[samsong]

That's a good idea.
The thing is if you want this library to be used on LARGE pages say you're loading 10,000 transactions,
I've found through testing that adding even that data-sort="181210" is more text and data the browser has to download.
Believe it or not this does slow down page load on large pages.
The best approach WHERE possible is to improve the handling of the sorter to detect these by just being told what type of field it is (eg date).
Declaring that it is a date is one line of text instead of 10,0000 (1 per transaction) to compensate.

Declaring a manual sort is good for fields which have no internal logic based on their value but you want to sort on them using an implied or relational logic.
For example I have a transaction list of people who owe money which are sorted by the % of money they owe in relation to their debt. So one person can owe $2 the other can owe $1. But the person who owes $1 is 3x more in debt and higher priority in the sorting than the $2.
Therefore by assigning a hidden sort method I can achieve the correct result.
Those are scenarios where you really have to use the override sort declaration.

If possible it's better to avoid it.