Link to home
Start Free TrialLog in
Avatar of Edward Joell
Edward JoellFlag for United States of America

asked on

Date with two digit Year converted to 20th Century Date by JavaScript Date() function.

Hi folks.  I have an Asp.Net MVC 4 app with a date field with a JQueryUI datepicker function.  The datepicker is set to format the data as MM/dd/yy by the JQuery function.
$("#WorkOrder_WODateCreated").datepicker("option", "dateFormat", "mm/dd/yy");

Open in new window

This is fine as long as the user uses the Date picker or manually types in '05/05/2013'  However, I had a user type in 05/05/20.  The in the change event handler, the JavaScript date function was used like this:
var createDate = new Date($("#WorkOrder_WODateCreated").val());

Open in new window

When stepping through the code it was found that createDate was set for "Wed May 5 00:00:00 EDT 1920

 Then when this code was run:
var startDate = new Date(Date.parse($("#WorkOrder_WODateCreated").val()));
                startDate.setMonth(startDate.getMonth() + 6);
                var formatedDate = $.datepicker.formatDate('mm/dd/yy', startDate);
                $("#WorkOrder_Estimated_Award_Dte").val(formatedDate);

Open in new window

The Estimated award Date was set to 11/5/1920.
 However when the data from the fields was submitted to an Ajax call to save the data the data in the CreateDate field was returned as "5/5/2020" but the Estimated Award Date stayed 11/5/1920.

What this seems to tell me is that JavaScript rules for converting a date with a two digit year are different than those of C#.

So I am interested in JavaScripts rules for setting century when presented with two digit dates, how they differ from C# and how can I get around these rules to force the conversion to be to a 21th Century date for a two digit date.

I tried changing to the datepicker assignment by adding the option yearRange like so
$(function () { $("#WorkOrder_WODateCreated").datepicker({ changeMonth: true, changeYear: true, yearRange: "2000:2100" }); });

Open in new window

But this did not help.

I tried searching the web but the search criteria seem to bring back every thing except for the conversion rules for converting two digit years in JavaScript.  Any ideas would be helpful.
ASKER CERTIFIED SOLUTION
Avatar of Imran Javed Zia
Imran Javed Zia
Flag of Pakistan image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Edward, you are correct in your thinking.  The Javascript mechanism for getting the year portion of the date, historically, has been time.getYear.  
The getYear() method returns the year minus 1900; thus:

    For years greater than or equal to 2000, the value returned by getYear() is 100 or greater. For example, if the year is 2026, getYear() returns 126.
    For years between and including 1900 and 1999, the value returned by getYear() is between 0 and 99. For example, if the year is 1976, getYear() returns 76.
    For years less than 1900, the value returned by getYear() is less than 0. For example, if the year is 1800, getYear() returns -100.
Source

The reference goes on to say that you should use getFullYear() instead of getYear().

In the past I would set the year by using something like:
var createDate = new Date($("#WorkOrder_WODateCreated").val());
if (createDate.getYear() >= 100 || createDate.getYear() < 0) {
	createDate.setFullYear(1900 + createDate.getYear())
} else {
	createDate.setFullYear(2000 + createDate.getYear())
}

Open in new window


But this now presents a problem as when the calendar rolls from 2099 to 2100 this script will break (not to mention that at some point getYear will be removed completely from the Javascript reference).

I would alleviate this issue by not allowing a two digit entry for the year to begin with.  But thats just me.

-saige-
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Edward Joell

ASKER

Its only a B because I had to resort to a work-around.