2

I've got the following which works fine in Chrome:

function funLoad(str1,str3,str4)
{

    var dym1 = str1.split("/");

    var d=new Date();
    var dym2 = d.getMonth() + 1 + " " + d.getDate() + " " + d.getFullYear() + " " + d.getHours() + ":" + d.getMinutes() + ":00";
    //var dym2 = "6 10 2013 09:00:00";

    var start = Date.parse(dym1[1] + " " + dym1[0] + " " + dym1[2] + " " + str3 + ":" + str4 + ":00"); 
    var end = Date.parse(dym2);

    return (start-end) / (1000*60*60);

}

$("#btn1").click(function(event){
    alert(funLoad($("#txt1").val(),$("#ddlHourTime").val(),$("#ddlMinuteTime").val()));
});

Here is a jsFiddle: http://jsfiddle.net/oshirowanen/QTVWd/6/

When I run this in IE8, I just get alerted with NaN.

Erik Schierboom
  • 16,301
  • 10
  • 64
  • 81
oshirowanen
  • 15,297
  • 82
  • 198
  • 350
  • might wanna take a look at [this](http://jquerybyexample.blogspot.com/2012/06/alert-your-visitor-to-upgrade-ie-using.html) fix (IE Alert) – ClydeFrog Jun 12 '13 at 11:44

2 Answers2

1

Looks like that format is not supported in IE

var dym2 = d.getMonth() + 1 + "-" + d.getDate() + "-" + d.getFullYear() + " " + d.getHours() + ":" + d.getMinutes() + ":00";
Arun P Johny
  • 384,651
  • 66
  • 527
  • 531
1

To simplify a little bit the error is because the format used by IE to store dates is not the same used by, for example, Chrome (and the one you're using to manually parse and format the date). It's allowed by the standard, what is required is the browser can parse the format produced by itself (see §15.9.4.2).

Usually to work directly with date format is not a good idea, not only because browser specific implementation but because of globalization (this is especially true for a web application with a virtual world wide audience). In practice what I mean is DO NOT EVER DO something like this (in this post I try to explain the reasons):

d.getMonth() + 1 + " " + d.getDate() + " " + d.getFullYear()

or this:

d.getMonth() + 1 + "-" + d.getDate() + "-" + d.getFullYear()

Few exceptions to this rule:

  • You're formatting that string for end-user (and only if you don't care about her date format, please note that with that code you're assuming MDY order and a specific separator).
  • You'll use that string by yourself and you'll parse it with another handmade parser (you won't use Date.parse()) because it's locale and browser dependent.
  • You're writing your own library to manage dates.

The only format you're sure every browser (that supports ECMAScript 5) will read is ISO 8601 YYYY-MM-DDTHH:mm:ss.sssZ (see §15.9.1.15) so in your case you should change your custom parsing/formatting to that. For older browser there is not a clear rule (that's why we need a library). The standard says at §15.9.4.2 that:

If the String does not conform to that format [ISO 8601] the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

(emphasis is mine)

Take a look to this and this posts on SO for other details (or this little tutorial about dates).

What I suggest, if you work with dates across browsers and locales, is to use a good library to abstract all this details. I found this one is pretty strong and easy to use. If you want a widely used almost complete library take a look to moment.js too.

Community
  • 1
  • 1
Adriano Repetti
  • 65,416
  • 20
  • 137
  • 208
  • “The only format you're sure every browser will read is YYYY-MM-DDTHH:mm:ss.sssZ” This is incorrect: it's a version of the ISO 8601 format and only supported by browsers that support ECMAScript 5. The only standard supported by all browsers is [RFC 2822](http://tools.ietf.org/html/rfc2822#page-14). [Source](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse) – Marcel Korpel Oct 31 '13 at 15:01
  • @MarcelKorpel sorry but you're wrong. What applies to **FireFox isn't standard**. The only requirement (from **standard**) is that browser can parse the date it produced (and _usually_ it's locale dependant so "1 Feb 2000" may be "2/1/2000" for you and "1/2/2000" for me). What you say applies for FF but what about IE, Opera, Safari, Chrome? In ES5 they introduced a standard format (ISO 8601) and it's the only one you can trust. If you specify a date **always** in dd/mm/yyyy format (as per the link you provided) it'll fail with, for example, Chrome on a Japanese machine... – Adriano Repetti Oct 31 '13 at 15:21
  • Libraries (like moment.js) exists to abstract this differences. If there was an universal standard the they had to be much more simple and without so many browser-dependant-tricks. – Adriano Repetti Oct 31 '13 at 15:29
  • The RFC 2822 is implemented in all browsers that support ECMAScript 3, including older browsers like IE 7. Moreover, you can feed the `Date` constructor a year, a month (zero-based) and a day, too. MDN does not only apply to Firefox, but includes information about other browsers, too. And internally, dates are not represented like "2/1/2000", but in numbers of milleseconds from the UNIX epoch. – Marcel Korpel Oct 31 '13 at 15:50
  • @MarcelKorpel of course they are not (represented as strings). RFC 2822 is **not** followed by all browsers! To follow it is just a design decision for FF. What I mean is: you write your code assuming Date constructor will understand a string with the format "dd/mm/yyyy". With FireFox it works in every country/locale. First user with IE (for example) and a locale with "mm/dd/yyyy" format will fail. Both browsers respect the ES3 standard but IE assumes "mm/dd/yyyy" (see MSDN) for short dates while FF assumes "dd/mm/yyyy" (see MDN). – Adriano Repetti Oct 31 '13 at 16:09
  • Can you see the difference? FF says it uses RFC 2822 but ES3 standard does not require to match what RS 2822 says about dates (see § 15.9.4.2 and related sections) so each browser has its own rules (and often it can't _guess_ so it'll just pick wrong date). – Adriano Repetti Oct 31 '13 at 16:11
  • The **only** date format mentioned in the standard is (§ 15.9.1.15) ISO 8601. If your string doesn't match it (let me cite § 15.9.4.2): "If the String does not conform to that format the function may fall back to any **implementation-specific heuristics or implementation-specific date formats**." For FF implementation specific is RFC 2822. For IE it's american date format. For Chrome (and brothers, if I remember well) it is locale dependant. Moreover they all try to guess if date can't match what they expect. – Adriano Repetti Oct 31 '13 at 16:17
  • Wow, I always thought that RFC 2822 was mention in ECMAScript 3. You're right, thanks for pointing me to this. Every day is a learning day. – Marcel Korpel Oct 31 '13 at 16:26
  • @MarcelKorpel you welcome, I read standard carefully only when I wrote this answer (sorry my English is so bad and I can't explain concepts very well). Before that I always assumed Date behavior is random (because in my locale format is "dd/mm/yyyy" and it didn't work in IE) but I didn't know why. – Adriano Repetti Oct 31 '13 at 16:28