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

Wrong date using Date.defineParser #1197

Open
MarcosFernandes opened this issue Jun 11, 2013 · 5 comments
Open

Wrong date using Date.defineParser #1197

MarcosFernandes opened this issue Jun 11, 2013 · 5 comments
Labels

Comments

@MarcosFernandes
Copy link

Hi,

Date is not being correcty formatted using dd/mm/YYY. Here's how to reproduce:
Date.defineParser("%d/%m/%Y");
console.log( Date.parse("02/04/2010") )

The output will be wrong:
Thu Feb 04 2010 00:00:00 GMT-0200 (BRST)

Note that if the day is above 12 the date is correctly parsed. IE:
console.log( Date.parse("28/03/2010") )

This is correctly parsed:
Sun Mar 28 2010 00:00:00 GMT-0300 (BRT)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@MarcosFernandes
Copy link
Author

This is inside Date parse function:

parsePatterns.some(function(pattern){
var bits = pattern.re.exec(from);
return (bits) ? (parsed = pattern.handler(bits)) : false;
});

Apparently the problem is that a date like "02/04/2014" is still valid for the pattern mm/dd/yyyy and therefore taken first from the "some" method above, while "29/03/2014" is not valid so it moves to the correct pattern.
I tried to use Locale, no luck though. Maybe I'm missing something...

@MarcosFernandes
Copy link
Author

I've found out that the more version I was using was missing the Locale definitions for pt-BR; so it works now.

It would still be nice to define a parser without having to touch Locale definitions - even documentation doesn't make this clear.
So it's up to you to decide if this still a bug or not.

A possible work around, would be to add an option on defineParser, so users can define their pattern priority, like this :

defineParser: function (pattern, options) {

    var pt;
    options = options || {};
    pt = (pattern.re && pattern.handler) ? pattern : build(pattern);

    if (options.prevails) {
        parsePatterns.splice(0, 0, pt)
    } else {
        parsePatterns.push(pt);
    }

    return this;
}

I don't know whether it's clean enough or if it's compliant with the framework patterns, though.

Anyway, thank you for your attention.

@SergioCrisostomo
Copy link
Member

Thank you, @MarcosFernandes , for bringing this up. We could at least be more clear in the docs about this. I will wait for others to check this also, and will reflect about it myself.

Obrigado!
Abraço

@anutron
Copy link
Member

anutron commented Apr 27, 2014

I don't have a problem with being able to specify parser priority, but I think the real thing to do is to make a note in the docs about this particular functionality and it's relationship with Locale.

SergioCrisostomo added a commit to SergioCrisostomo/mootools-more that referenced this issue Apr 28, 2014
Date uses Locale for location. This is not documented and needs to be
more clear. I Added more info only in .defineParser (singular) not in
plural version...
@SergioCrisostomo
Copy link
Member

@arian could you also give some feedback about this issue and PR #1100?
There is also one more Date.parse related PR: #1106

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants