Date parsers are a little too rigid #125

Closed
cautionbug opened this Issue Aug 29, 2012 · 3 comments

Comments

Projects
None yet
2 participants

i discovered this in the last version from the original plugin (2.0.5): the usLongDate & time regular expressions are a little too rigid for some date outputs, depending on the DBMS used.

For instance, in usLongDate, MSSQL doesn't put a space between the 12-hour time & AM/PM (ex. 08:09:25AM). The regular expression requires a space or the date interpretation fails.

i made some revisions to the expressions that i hope will be helpful. If not, shrug okay.

    ts.addParser({
        id: "usLongDate",
        is: function (s) {
            return /^[A-Z]{3,10}\.?\s+\d{1,2},?\s+(\d{4}|'?\d{2})\s+(([0-2]?\d:[0-5]\d)|([0-1]?\d:[0-5]\d\s?([AP]M)))$/i.test(s);
        }, format: function (s) {
            return $.tablesorter.formatFloat(new Date(s.replace(/(\S)([AP]M)$/i, "$1 $2")).getTime());
        }, type: "numeric"
    });

    ts.addParser({
        id: "time",
        is: function (s) {
            return /^(([0-2]?\d:[0-5]\d)|([0-1]?\d:[0-5]\d\s?([AP]M)))$/i.test(s);
        }, format: function (s) {
            return $.tablesorter.formatFloat(new Date("2000/01/01 " + s.replace(/(\S)([AP]M)$/i, "$1 $2")).getTime());
        }, type: "numeric"
    });
Owner

Mottie commented Aug 29, 2012

Thanks! I do appreciate the help :) and I'll include this in the next update.

Glad to help. i noticed there are slight differences in the old function signatures & new ones, plus your changes use the internal ts. object rather than going up to global & back down ($.tablesorter)... Adjust as needed. :-)

Owner

Mottie commented Sep 27, 2012

Added to version 2.4. Thanks again!

Mottie closed this Sep 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment