No, the strategy there doesn't handle Date Localization for you.
Javascripts internal Date Object does take Localization in account. But thats just depending on the Browsers/Machines Locale settings
Which does not necessarily have to match the Users Date format,sitting infront of it
And you can't distinguish a DD/MM/YYYY from a MM/DD/YYYY format. exception for: DD > 12
without further information about the user .
You could of course use the localization from the browser/machine or the ip adress to get a location or something else,
and handle the formating depending on this information, but this could easily lead to wrong results.
I would rather make sure that the Date
Object is constructed right.
For example by providing a Date Picker which lets the user choose the Year Month and Day respectively to avoid the Date ambiguity due to their format.
Because you can't make sure what format the user, sitting at the PC is using.
e.g: I'm european and have my Browsers Locale Settings on enUS.
Therefore the
Then you can construct your Date Object like new Date(YEAR,MONTH,Day)
e.g ->
var year1 = 2013; //Suppose those variables will be handle by some user input method
var year2 = 2013;
var month1 = 0; //January (Months are zero based in javascripts Date Object)
var month2 = 3; //April
var day1 = 3;
var day2 = 1
var date1 = new Date(year1,month1,day1);
var date2 = new Date(year2,month2,day2);
console.log(date2.getTime() > date1.getTime()); //true
And avoid that Problem at all