We Keep Coding

Date parse month format

While creating/testing a date adapter in my Angular project I ran into this issue. I think I must be missing some convention, but when changing the month to a single digit like 2 (for February) rather than 02, I get a different day.
Date.parse is giving two different outputs based on that different as pictured below. Any thoughts?

According to the documentation:
The ECMAScript specification states: If the String does not conform to the standard format the function may fall back to any implementation–specific heuristics or implementation–specific parsing algorithm.
Here, the second string does not match the expected format, and Chrome does something with it.
If you test it with Firefox, the same date is returned, so it's a Chrome "issue".
You can try to read V8's source code to understand why you get this and how it is actually implemented.
This isn't a lot of help, but I don't think you'll find anything without getting to the bottom of V8.

toISOString not working in firefox

I am creating a new date toISOString -
new Date(03-13-2016 00:00).toISOString();
This works fine in IE and Chrome however NOT in FireFox.
I have tried to modify the string slightly like -
new Date(03-13-2016T00:00:00Z).toISOString();
However this also failed. How can I achieve the desired result to work across all browsers?
2016-03-13T00:00:00.000Z
PS I am aware I start with a string then try and create a string with the toISOString - reason being this handles timezone offset to UTC in one line which is required.

When you pass a string to the Date constructor, it internally calls Date.parse to attempt to get a valid date from it. This first checks to see if it is one of the Date Time formats in the specification. If not (and both "03-13-2016 00:00" and "03-13-2016T00:00:00Z" aren't), the parse specification goes on to say:
If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats. Unrecognizable Strings or dates containing illegal element values in the format String shall cause Date.parse to return NaN.
In this case, it seems both IE and Chrome have code in place that allows it to be correctly parsed, while Firefox doesn't. The only way you're really going to fix this is to have a string that conforms to the specification, or to call the constructor with individual date/time component parts.

If you don't mind pulling a library in or need to work with dates more often, use moment.js which has some very convenient date and time methods and is cross browser compatible.
Your string could then be converted to an ISO String like:
moment('03-13-2016 00:00', 'MM-DD-YYYY HH:mm').format();

IE 11 issue with JavaScript toLocaleDateString() formatting

I am using the JavaScript Date function toLocaleDateString() to format my date to look like 8/13/2014, but for some reason when I try to send this value via an API call by doing a JSON.stringify and then AJAXing the value, IE decides to change the actual value to be ?8?/?30?/?2014.. This obviously causes errors on the back end.
Why does IE do this and how can I fix it?

Looks like it's a bug that was introduced in IE 11. IE 11 uses Unicode chars, so what you see is U+200E 'LEFT-TO-RIGHT MARK'
What you can do as a temporary solution to fix this issue is to replace that char. Like this:
console.log((new Date()).toLocaleDateString().replace(/\u200E/g, ''));

You should check out the answer here:
ToLocaleDateString() changes in IE11
You shouldn't be using a function intended to format something for locale-specific human display and expect the output to be machine parsable. Any of the output of toLocaleString, toLocaleDateString, or toLocaleTimeString are meant for human-readable display only. (As Bergi clarified in comments, toString is also meant for human display, but ECMA §15.9.4.2 says it should round-trip)
Although the function returns a string, it's only human-readable and is never appropriate for machine parsing. I'm not 100% sure what encoding it is for IE, but although it looks like a string, underneath it uses a different encoding.
For date formatting, you may wish to use Moment.js, or just write your own formatting function.

Javascript - Retrieve OS Date formatting

Hmmm... Okay so I've been searching the web for 2 days now without any luck. I've seen a lot of answers on how to format a javascript date for example new Date().toString("yyyy-MM-dd")... Which would return something like 2013-04-05.
This is absolutely not the problem.
What I want, is the possibility to set the format in which my OS displays dates, then retrieve that specific format and display it in the browser.
For example, let's say I changed the format of the date in my OS to MM-yyyy/dd (this is for arguement sakes, whether that would work or not is irrelevant)). Then I'd expect to see 04-2013/05 in my OS, right? Next I want to retrieve this specific format in my browser via Javascript so that I can use this to format my dates throughout my webpage.
If this is lunacy and cannot be done, please tell me, as I've got a headache from searching.
Also, if you say use someDateObject.toLocaleDateString() without explaining exactly why .toLocaleDateString would work, I'm going to ignore it, because I've tried setting my date-format in my OS to numerous formats and every single time I use .toLocaleDateString(), I receive the same format: dd/MM/yyyy

first attribute of .toLocaleDateString method locale(s) used.
current locale you can obtain through navigator.language (in firefox or chrome) parameter.
in IE you can obtain navigator.browserLanguage or navigator.systemLanguage
in browsers other than IE it is impossible to obtain system language this way
after this you can call new Date.toLocaleString(navigator.language||navigator.browserLanguage) and it will be formated correctly depending on browser language

Python - date object from Windows machine -- time zone issues

I have a jQuery app that sends a date object to python for parsing. The problem is that when I try to use my jQuery on the Windows machine, the date object looks like this:
Tue Mar 12 2013 00:00:00 GMT-0600(Mountain Daylight Time)
Whereas on my Mac, I get:
Tue Mar 12 2013 00:00:00 GMT-0600(PST)
When I try to parse these in Python with the strptime function, it fails because it doesn't understand the time zones on the end of the first (the MDT one). It complains that is an "unknown string format".
How do I resolve this? Am I doing something wrong?

The best solution here is probably to have your jQuery code convert its datetimes to GMT before sending them. (If you want the timezone as well, send it separately.) Then you can get them out of the JSON (or whatever) on the Python side, turn them into GMT datetime objects with strptime, and use them, and you're done.
But the simplest solution,* with the least code change, is to just let jQuery do the wrong thing and throw away the timezone on the Python side. Basically, instead of this:
dt = datetime.datetime.strptime(jsondate)
do this:
dt = datetime.datetime.strptime(jsondate.partition('(')[0])
Notice that throwing away everything after the '(' still leaves you with the -0600 part; you're just losing the "PST" or "Mountain Daylight Time" part.
And those parts were not doing you any good anyway. datetime doesn't understand these timezone names. And, even if it did, it has nothing to map them to except for offsets (which you already have). If you want real timezones, you need some third-party library like pytz.**
On top of that, strptime specifically returns naive datetime objects, not aware ones. So, even if datetime could parse and look up the timezones, it still wouldn't do anything useful with them, unless you parsed the datetime, then pulled out the timezone and parsed it separately and looked it up and then called astimezon on the datetime.
So, in summary, the worst-case scenario for throwing this information away is exactly what you already have.
As a side note, on three projects in a row, I pushed a datetime serializer into my JSON en/decoder on the Python side (and a matching serializer on the JS side, for the one that had a JS side) specifically so I could pass a UTC datetime (in ISO8601 format, because that's as easy to use for computers as a seconds-since-epoch, and a lot easier to read/edit for humans) and a timezone offset today, but switch to a tzinfo key if it because important later. All three times, it never became important… And the projects where it has been important, I've usually been passing around ICAL schedules or pre-Gregorian dates or other similarly fun stuff.
Finally, as someone who's written way too much date-related code over my career, I have to say this: If you know of any evil overlords planning to take over the world, if they promise to abolish timezones, I am willing to overlook their other programs of enslaving humanity or making kittens fight babies and sign up as a henchman.
* … at least simplest for me, since I know Python a lot better than JS and jQuery. :)
** IIRC, pytz can't handle NT-style timezone keys like "Mountain Daylight Time" either, so you actually need yet another library to handle that. I think I got that out of a library that did all kinds of MS datetime stuff, including handling the differences between Microsoft's three similar 1601-ish epoch times (two not-quite-the-same epochs, different rules for special "end of time" and "start of time" and "not a date" values, …).