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();
Related
This is javaScript code, new Date() returns invalid value.
Do I need change the date format before pass it to new Date()?
new Date("25-Feb-17");
On MDN, you can read the following about this particular Date constructor:
Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
If you want the constructor to work correctly across all browsers, either use one of its other variants (also described on the linked MDN page) or at least reformat your date string to be compliant with the ISO8601 date representation. The latter option isn't 100% guaranteed to work though since JavaScript uses a slightly simplified convention for representing dates as strings; you might find corner cases that will fail.
Also, as per the quoted note, there's a caveat. Using simplified date formats such as "2017-02-25" will be treated as UTC, but then internally translated to your local timezone. Assuming you're on the western hemisphere, the final result will be February 24th instead.
Its not working on Firefox, tested on Chrome and worked fine so I suggest you to use the standard Date object creation as follows:
new Date(year, month, day, hours, minutes, seconds, milliseconds)
I have a requirement to convert date time in moment.js. But it gives me different result in Chrome and Firefox.
In Google Chrome it gives correct result but in Mozilla firefox gives "Invalid date".
Google chrome
moment('2016-Jan-02 02:00 AM').format()
Output: "2016-01-02T02:00:00+05:30"
Mozilla firefox
moment('2016-Jan-02 02:00 AM').format()
"Invalid date"
Your help is much appreciated.
It's recommended to avoid using moment parsing with custom format. As the documentation states:
Warning: Browser support for parsing strings is inconsistent. Because there is no specification on which formats should be supported, what works in some browsers will not work in other browsers.
For consistent results parsing anything other than ISO 8601 strings, you should use String + Format.
In your case, the code for consistent parsing will be:
moment('2016-Jan-02 02:00 AM', 'YYYY-MMM-DD HH:mm A')
You're not specifying a format for parsing the string 2016-Jan-02. So moment falls back to the native Date object, which is inconsistent across the different browsers. To parse the date consistently, include a format string along with it.
e.g.
moment("2016-Jan-02", "DD-MMM-YYYY")
Then if you want to format the moment object as a string, you can do what you were doing before:
moment("2016-Jan-02", "DD-MMM-YYYY").format("DD-MM-YYYY")
which returns the string 02-01-2016 in both browsers.
You need to specify input date format inside moment
moment("input_date_string", "format_of_input_date_string").format("format_of_output_date_string")
eg:
moment("27-06-2022", "DD-MM-YYYY").format("YYYY-MM-DD")
output:
2022-06-27
I have a very simple operation by converting a string in standard format 1985-10-11T12:23:00 (without timezone specified).
Data.parse() in chrome javascript parses it in Date object as is, but in Firefox a correction for time zone applies.
How I can ensure that in both browsers Date.parse produces result without timezone corrections?
I would suspect
new Date("1985-10-11T12:23:00").toUTCString()
I have figured that out. Date.Parse accepts information about time zone so to ensure cross-browser compartibility, time zone must be added to the zone-less time stamp.
But most commonly used Z+00 notation does not apply. as per Date Parse doc, one has to specify e.g. UTC timezone as +00:00 right after timestamp
If I call this in Firefox (32) or IE (11), it will be parsed as local time:
new Date('2014-10-02T12:00:00')
However, if I parse it in Chrome (37.0.2062.124 m 64-bit), it will be parsed as UTC time.
How can I parse it as local time uniformly across all browsers?
Per ECMA-262, this is, in fact, a valid date format, but a bug may have been the cause for the original discrepant browser behavior.
Try using the time zone indicator from ISO 8601 date standard (append a Z to the end of the timestamp), and see if that helps.
Honorable mention: Moment.js is wonderful for parsing dates, but it’s a hefty lib so that comes with its own trade-offs.
While trying to parse an ISO-8601 formatted string in Javascript, I noticed that it cannot parse the string when the offset lacks the minute part. E.g:
Date.parse("2014-05-16T07:28:51.148412+02")
results evaluates to NaN, whereas
Date.parse("2014-05-16T07:28:51.148412+02:00")
evaluates to 1400218131148. This was confusing me, as both NodaTime (where the string without the minutes gets generated) and Javascript seem to support ISO-8601. What is interesting is that different sources make different statements about whether the minute part is required or not: Wikipedia says it is optional whereas this document says it's not.
So what is the correct specification? Should I even file a bug for NodaTime that they don't follow the standard? And what would be a workaround? I can't seem to get NodaTime to produce the offset with minutes.
Noda Time follows the ISO 8601 specification (if you don't want to buy it, you can find draft specifications for free) correctly. However, the Date object in Javascript doesn't follow ISO 8601, but a format based on that standard.
If you look in the ECMA-262 specification (which applies to Javascript), you see that Date.parse must understand the so-called Date Time String Format. It's "based upon a simplification of the ISO 8601 Extended Format", and requires the time zone specifier, if present, to be Z, +hh:mm or -hh:mm.
See #Rhymoid's answer for information on the standards. I just add the solution that I finally took to parse ISO-8601 formatted dates in JavaScript.
There is a library called Moment.js, which is able to parse ISO-8601:
moment("2014-05-16T07:28:51.148412+02")
This returns a valid date object with the specified offset.