0

So I came across this odd interaction between Javascript Date objects being converted into Strings and the in operator in IE11. The String that .toLocaleString() returns for a date, doesn't work when checking for keys using the in operator, even through another string with the exact same text works just fine.

The interaction works correctly in Chrome, but seems to fail in IE11. What am I missing here and is there a way to get around this?

let days = {
  Monday: {},
  Tuesday: {},
  Wednesday: {},
  Thursday: {},
  Friday: {},
  Saturday: {},
  Sunday: {}
};

// The example date should be a Monday
let currentDate = new Date('2018/8/20');
let currentDay = currentDate.toLocaleString('en-us', {
  weekday: 'long'
});

console.log(currentDay);
console.log(typeof currentDay);
console.log(currentDay in days);
console.log('Monday' in days);

Thanks for any input!

Chase Ingebritson
  • 1,559
  • 1
  • 12
  • 25
  • You've apparently missed "Invalid date" log in IE ..? – Teemu Aug 20 '18 at 18:10
  • What do you mean? – Chase Ingebritson Aug 20 '18 at 18:14
  • 1
    `console.log(currentDay);` logs "Invalid date" in IE11. – Teemu Aug 20 '18 at 18:14
  • Odd, sorry about that. I was getting a valid date on my localhost. I’ll double check when I get back to my computer. – Chase Ingebritson Aug 20 '18 at 18:28
  • `'2018-8-20T00:00'` would create a valid date in IE, or `'2018/8/20'`. – Teemu Aug 20 '18 at 18:46
  • 1
    @teemu—but then you'll get an invalid Date in Safari. ;-) – RobG Aug 20 '18 at 20:31
  • Your issue is using the built-in parser, see [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) Also, the value returned by *toLocaleString* is implementation dependent, you can't guarantee the result. – RobG Aug 20 '18 at 20:33
  • So it sounds like the solution in this case would be to use `.toString()` or `.toUTCString()` and use my own custom parser to pull out the day of the week, or use a 3rd party library like moment.js that has this built in. – Chase Ingebritson Aug 20 '18 at 21:09
  • @ChaseIngebritson—yes, a *real* parser and formatter would help. Moment.js is good, but there are many to choose from. Others are [*luxon*](https://moment.github.io/luxon/) (full–featured) and [*fecha*](https://github.com/taylorhakes/fecha) (small, efficient parsing and formatting). *toLocaleString* can be handy, but for comparisons it's a bit useless (implementation dependance and all that). – RobG Aug 20 '18 at 21:57
  • @RobG Thanks again for all the help! For anyone that sees this question, I ended up going with fecha and it worked perfectly for the plugin. – Chase Ingebritson Aug 21 '18 at 16:19

1 Answers1

0

This is basically why you should stick to ISO date strings (2018-01-01T00:00Z) and not use arbitrary formats.

Alternatively, parse the format yourself and use the other overload of the new Date() constructor like so:

const currentDate = new Date(2018, 7 /* months start at 0 */, 20 /* days do not */, 0, 0, 0)

Date parsing is bad, and IE is bad, and two bads don't make a good in this case.

It's not the in that's wrong. Your date is invalid in IE.

RobG
  • 142,382
  • 31
  • 172
  • 209
Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308