8
  1. new Date().toLocaleDateString('en-US'); // "‎8‎/‎17‎/‎2018"
  2. new Date("8/17/2018") //valid date
  3. new Date(new Date().toLocaleDateString('en-US')) // Invalid Date

I am trying to create date from local date string (see screenshot) but its not working in IE11 only. It works with normal date string though.

I know something wrong with "" double quotes but not able to get it working.

Any suggestion ?

enter image description here

Saikrishna Rajaraman
  • 3,205
  • 2
  • 16
  • 29
Dipak Telangre
  • 1,792
  • 4
  • 19
  • 46
  • The string should be an RFC2822 or ISO 8601 formatted date. Reference : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse – Wilfred Clement Aug 17 '18 at 09:50
  • Same issue with ```momentjs``` – Dipak Telangre Aug 17 '18 at 09:53
  • [What are valid Date Time Strings in JavaScript?](https://stackoverflow.com/questions/51715259/what-are-valid-date-time-strings-in-javascript) – str Aug 17 '18 at 16:00

2 Answers2

2

Seems it can be done like this 

new Date(new Date().toLocaleDateString('en-US').replace(/[^ -~]/g,''))

Snapshot from ie11

Reference Answer

brk
  • 48,835
  • 10
  • 56
  • 78
  • ```It worked ``` – Dipak Telangre Aug 17 '18 at 10:09
  • @jackjop—you don't seem to know what you're looking at. The output of *toLocaleString* is implementation dependent, browsers are not required to be able to parse it and you should not expect that they can. There are many strings that can be generated from *toLocaleString* that can't be parsed by any browser, much less IE. On the other hand, the output of *toString* is now standardised and current browsers are required to parse it. – RobG Aug 18 '18 at 06:31
  • @RobG `new Date().toLocaleDateString('en-US')` and `new Date().toLocaleDateString('en-US').replace(/[^ -~]/g,'')` will give me the same output (at least in a few browsers I tried, including IE11). So what difference is there between `replace(/[^ -~]/g,'')` and `toString()` in this case? I don't quite understand it. I couldn't find any resources about this problem. – sertsedat Aug 18 '18 at 10:52
  • 3
    @jackjop—it's not a good idea to rubbish a product without sound reasons. The key here is that the result of *toLocaleDateString* is implementation dependent and browsers are not required to be able to parse it. The fact that some random code produces a desired result with no idea of how or why it works is not a suitable basis for suggesting its adoption. :-( – RobG Aug 18 '18 at 11:07
  • @RobG, I see. So we only need to accept it and have workarounds. Thank you for explanation! – sertsedat Aug 18 '18 at 11:09
1

just use momentjs for this.

moment("8/17/2018", "L").format() would output:
"2018-08-17T00:00:00+02:00"

(+02:00 is my local timezone. you can specify to use utc or another timezone too.)

also keep in mind L is dependent on the timezone profile you installed. this is the default en one.

you could also replace "L" with "MM/DD/YYYY"

the second argument of moment always specifies the format of your input.
it is also able to guess the input but you need to experiment with that.

.format("L") is essentially the same but in the output direction.

GottZ
  • 4,824
  • 1
  • 36
  • 46
  • 1
    "*Use library X*" answers aren't helpful. The OP's question is why the built–in parser doesn't correctly parse the output of *toLocaleDateString* (which is implementation dependent and may differ even with the same language tag). – RobG Aug 18 '18 at 06:35
  • while i agree on avoiding "library x" answers, i kindly disagree in case of `Date`. yes you can make stuff work but you can never be 100% certain that your code will run in all browsers if you are relying on automated parsing rather than using `Date` properly. i throw momentjs at people because it removes this usually failing dependency. – GottZ Aug 19 '18 at 10:47
  • how will smart TV x run your code? how will it run on a playstation vita? what about the samsung browser on old phones? how about opera mini? what about opera mobile? – GottZ Aug 19 '18 at 10:48
  • they all run momentjs just fine. – GottZ Aug 19 '18 at 10:49
  • To use any parser, you need to know the format so you can tell the parser what it is. The OP's issue is that the output of *toLocaleDateString* is implementation dependent, so they don't know the format, so can't tell the parser even if they use one that takes a parse format (like moment.js). It's important to tell the OP why they have their issue and how to solve it without a library (since there's no library tag or mention of one). You might include a solution using a library, but your answer shouldn't use only a library not tagged or mentioned in the OP. – RobG Aug 19 '18 at 14:03
  • PS. Parsing a date in format MM/DD/YYYY is 2 lines of code that will run in any ECMAScript implementation compliant with ed 1 or later, i.e. any commercial implementation in use. :-) – RobG Aug 19 '18 at 14:05
  • ye. it's quite easy if you know what you do.. `var d = "05/10/2018".split("/"); new Date(+d.pop(), +d.shift()-1, +d.shift())` or even using something like Date.UTC... still.. if this is not the only format one has to deal with. both of us know that. – GottZ Aug 19 '18 at 19:44
  • "*…this is not the only format one has to deal with*". Exactly. The OP doesn't know what *toLocaleDateString* will produce across every implementation that might run the code, so can't reliably parse it, with or without a library. – RobG Aug 19 '18 at 22:01