I have two date fields (Start Date & End date) which i want to compare (End date should be greater than Start Date). For comparing i'm using Date.parse() of javascript.

When the locale of my SF instance is English(US) i'm able to compare them without any issues. But, when i change the locale to English(UK), i'm unable to compare them. In this case, variable having Date.parse method is displaying 'NaN'

Any ideas on how to handle it?

Javascript Code:

function validations()
    var condition = 0;
    var startDate = Date.parse($('.startDate').val());
    var endDate = Date.parse($('.EndDate').val());
    //alert('startDate'+startDate+'endDate' +endDate );
    if(startDate >= endDate )
        condition= condition+1;
        alert('end date should be greater than start date');
        return false;

    if(condition== 0) return true ;

    else return false;


VF Code:

        <apex:inputText value="{!startDate}" styleclass="startDate"/>
        <apex:inputText value="{!EndDate}" styleclass="EndDate"/>
  • Please share the code that you have implemented this comparison. Commented Apr 28, 2015 at 8:35
  • Thanks Rajiv Bhatt. I have added my code to my question itself.
    – Rv1
    Commented Apr 28, 2015 at 8:37
  • @Rv1: Check out the moment.js library momentjs.com.. This might of some help..
    – Sam
    Commented Apr 28, 2015 at 10:26
  • Did you consider apex for this? I feel JS is getting confused on the different date format. Commented Jan 1, 2016 at 18:23

4 Answers 4


Date formats vary based on the locale. Often JS libraries will look at the locale of the browser, which usually makes sense. SFDC is a special case because it keeps a locale for the user on the server. When the two locales disagree, parsing of date/time can be difficult. For example, my browser might be set to the US locale (mm/dd/yyyy hh:mm AM/PM) but Salesforce may have me in the German locale (dd.mm.yyyy HH:mm) resulting in SFDC rendering a date such as "31.12.2017 23:39". A JS parse of that will fail since it's looking for the US format as specified in the browser. Using date/time pickers may not solve the issue in an appropriate way. While they will be parseable, the format will likely be the browser's and not the SFDC user's specified format. I've struggled with this a bit, and haven't found anything elegant to solve it. The actual values for date/time pickers are also an issue since the parsed value will be in the browser's time zone, not the SFDC time zone, but a relatively simple conversion can work here, if you ask to for the parsed input's GMT time, and then user the locale in SFDC to convert it to the users time. But for endtime>starttime that should not be an issue.


As a start, I would make sure that the input is being handled correctly in the page before validating it.

Is there a reason you are not using inputField with type='type' and showDatePicker='true'?

  • Sorry Mark. I didn't mention this before: I'm using bootstrap model for poping for date fields. Date values are passing correctly to validations function after clicking submit button(i didn't include this too in above sample code.My apologize for that) in mm/dd/yyyy HH:MM format.
    – Rv1
    Commented Apr 28, 2015 at 9:29
  • Ok, so your SF locale gets localised to UK, but what about the page and the JavaScript?
    – Mark Smith
    Commented Apr 29, 2015 at 11:13
  • Sorry,I didn't get your question. would you please expand it.
    – Rv1
    Commented May 21, 2015 at 10:10

I am not sure of some standard way of doing same but a custom function of below type can be used:

function convertUKDate(strToConvert){
    var temp=strToConvert.split("/");
    return temp[1]+"/"+temp[0]+"/"+temp[2];

Then you can change your syntax like:

var startDate = Date.parse(convertUKDate($('.startDate').val()));
var endDate = Date.parse(convertUKDate($('.EndDate').val()));
  • the problem is that the "/" isn't always used as a separator. So while this can work for UK, it will not for many other locales, such as Germany or French Canada.
    – Jochen
    Commented Jun 28, 2017 at 15:08

If it's in a Visualforce page, why not use regular Validation Rules for that object?

  • 1
    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
    – glls
    Commented Feb 20, 2018 at 17:54
  • I disagree. It is an answer. Perhaps I should have used a statement and not a rhetorical question: Instead of doing validation in Javascript, because it is a Visualforce page, a Validation Rule would work well here. Commented Feb 20, 2018 at 22:07
  • @DavidSchach Your solution doesn't works me in above scenario. Because, I'm not referencing the inputFields here. They're code level variables. However, I appreciate your response. Thank you.
    – Rv1
    Commented Feb 26, 2018 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .