we are trying to format date in an e-commerce JavaScript application.
We have tried using appending "00:00:00" to the date String.
But in IE 11, with that string we are getting a Invalid Date error.
So we have tried a few more options but the the date Object we are getting is unexpected:
1. new Date(2017, 02, 10, 00, 00, 00, 000) -->
Fri Mar 10 2017 00:00:00 GMT-0800 (Pacific Standard Time)
2. new Date("2017-02-10T00:00:00.000Z") -->
Thu Feb 09 2017 16:00:00 GMT-0800 (Pacific Standard Time)
Is the only effective way is to use "moment.js" to solve these issues.
Thanks and Regards
It is unclear whether you're asking about creating dates or formatting them as strings. But there is nothing unexpected here.
new Date(2017, 02, 10, 00, 00, 00, 000)
You should not use leading zeros on numbers. In some instances in older browsers it can indicate octal rather than decimal. Anyway, the above will produce a "local" date for 10 March 2017 at 00:00:00 based on the host system time zone setting. Yours seems to be set for UTC-08:00.
Given:
new Date("2017-02-10T00:00:00.000Z")
you're asking the Date constructor to parse a string, something it's notoriously bad at. However, browsers older than IE 8 should parse it correctly and produce a date for 10 March 2017 at 00:00:00 UTC, which has a timezone offset of 00:00.
Since your timezone is -08:00, when you write it to output the values will be adjusted for the host timezone (i.e. local) so you see a date for 9 March 2017 at 16:00:00 (or 4 pm).
Note that using the built–in Date.prototype.toString will result in an implementation dependent string that may be different in each host. If you need information on formatting a date, see Where can I find documentation on formatting a date in JavaScript? or How to format a JavaScript date.
Is the only effective way is to use "moment.js" to solve these issues.
It's unclear what issues you're trying to solve, however a good, light, parsing and formatting library is fecha.js. If you also want to do arithmetic, you might find moment.js suitable. But it's not difficult to write a function to parse specific formats or create suitable strings, see the above links.
Related
Used ng prime datepicker in application.
Getting date in Fri May 14 2021 00:00:00 GMT+0530 (India Standard Time) format as response from api.
Then converting Fri May 14 2021 00:00:00 GMT+0530 (India Standard Time) this response with new Date().
Then binding the response to ng prime datepiker.
Working fine in chrome.
In firefox it is showing "Invalid date".
See the documentation for the Date constructor:
A string value representing a date, specified in a format recognized by the Date.parse() method. (These formats are IETF-compliant RFC 2822 timestamps, and also strings in a version of ISO8601.)
Since you aren't passing one of those formats, you are dependent on implementations having non-standard support for your format.
Chrome does. Firefox doesn't.
Use a date parsing library that lets you specify the format (such as date-fns/parse) or change the API so it outputs dates in the standard format.
You can as well, use the dateStringToDate function in date-fran module. It converts date formats of the form "Fri May 14 2021" to actual date instances.
I am using new Date() to create a date object for a specific date. But it returns two different dates in different timezones. See below:
When my machine is in Indian Timezone (IST)
console.log(new Date('2020-08-28')); //returns Fri Aug 28 2020 05:30:00 GMT+0530 (India Standard Time)
When my machine is in US timezone (CST)
console.log(new Date('2020-08-28')); //returns Fri Aug 27 2020 19:00:00 GMT-0500 (Central Daylight Time)
How is this happening even when I am telling the JS to create a date for a given string? The string here is '2020-08-28'.
Why is this happening and how to ignore the timezone in this case?
From the ECMAScript specification:
When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
The forms themselves are described in the Date Time String Format.
It is important to note that treating date-only forms as UTC is in conflict with the ISO 8601 spec which treats such forms as local time. This is a known issue and was done deliberately in the name of "web reality".
When you instantiate a Date by passing a string, it's supposed to be a full ISO 8601 string which specifies the time zone. As you dont specify it, it takes Greenwich Mean Time (±00:00), then uses your local timezone when displaying it. Use this if you want to display the date as GMT:
console.log(new Date('2020-08-28').toUTCString());
My computer is with US region settings and date formats and -8h GMT timezone, but i am not exactly in US region. Why when getting the date through new Date i can see that the timezone offset is correct, but when i try and convert it to localedateString i get my really local date string?
var date = new Date();
///here date is (for example) Mon Jan 15 2001 12:00:00 GMT-0800 (Pacific Standard Time)
var localeString = date.toLocateDateString();
///or date.toLocaleString()
/// localeString here comes in my real locale date format 15.01.2001 г or 15.01.2001 г., 12:00:00 when using toLocaleString()
The output of toLocaleString is entirely implementation dependent and is inconsistent across browsers currently in use. It does not necessarily respect system settings (e.g. Chrome does not respect my system settings for the order of the components) and there is no requirement in ECMA-262 for it to do so.
For reliable results, format the output manually in an unambiguous format, e.g. 25 Feb 2017. A library can help, but if you only need one format then a simple function will suffice.
I am looking for a date format (only year, month and day, no time component), that will be guaranteed to be interpreted as local time, in all reasonably modern browsers, when passed to the Date() constructor in JavaScript.
The (3-letter English month abbreviation) (2-digit date) (4-digit year) format seems to work. When I do new Date('Apr 01 2015') on my English system, in Chrome, with my machine being in the Eastern timezone, I get back Wed Apr 01 2015 00:00:00 GMT-0400 (Eastern Daylight Time) which is exactly what I want.
However, I am not sure if this (3-letter English month abbreviation) (2-digit date) (4-digit year) format is guaranteed to be interpreted in the same way regardless of browser and browser/OS locale/language.
Will this format work the same way across different (reasonably modern) browsers and locales? If not, then is there some other format that will work?
Please note that ISO-8601 doesn't answer this question. ISO-8601 date-only strings are interpreted as being in UTC, and not in local time, so new Date('2015-04-01') is interpreted as Tue Mar 31 2015 20:00:00 GMT-0400 (Eastern Daylight Time), i.e. April 1 turns into March 31, which is not what I'm looking for.
I am looking for a date format (only year, month and day, no time component), that will be guaranteed to be interpreted as local time, in all reasonably modern browsers, when passed to the Date() constructor in JavaScript.
There isn't one. There are a number of formats that, in practice, are reliably parsed by all browsers in use however none of them are required by ECMA-262 to be supported by ECMAScript implementations.
There is one format, a version of ISO 8601, that is specified in ES5 and ECMAScript 2015 however dates without a time zone are to be treated as UTC in ES5 and "local" in ECMAScript 2015.
But that was seen by implementers as "breaking the web", so while some browsers implemented that for a while, they have now reverted to ES5 behaviour and treat a missing timezone as UTC.
A small change in format such as changing the separator from "-" to "/" causes a reversion to implementation dependent behaviour and may cause the date to be treated as UTC or local (though most seem to treat 2015/12/17 as local).
So if you want a guarantee, there isn't one. However, if you are prepared to write a 2 line function, you can parse an ISO 8601 like string reliably based on whatever time zone you like. If you want it to be treated as local (i.e. set to 00:00:00 and offset based on system settings), then:
function parseISOLike(s) {
var b = s.split(/\D/);
return new Date(b[0], b[1]-1, b[2])
}
document.write(parseISOLike('2015-12-17'));
will do the job (without checking for valid values) and allow the separator to be any non–digit, so 2015/12/17, 2015-12-17 and 2015.12.17 will all be correctly parsed.
Edit
Parts of the above have been edited thanks to input from Matt Johnson.
I am using date.js in my project, and I am encountering something I didn't expect with respect to dates that had time components of exactly noon or exactly midnight.
When I use the native javascript Date.parse method, I get the result I expected when parsing a date:
// plain old javascript
var date = new Date(Date.parse("10/21/2010 12:00:00 PM"));
alert(date);
I get this:
Thu Oct 21 2010 12:00:00 GMT-0500 (Central Daylight Time)
I interpret this as noon on October 21, 2010, which is what I think my input date is. However, when I import date.js and try something similar,
// using date.js
var date = Date.parseExact("10/21/2010 12:00:00 PM", "M/d/yyyy hh:mm:ss tt");
alert(date);
I get this:
Fri Oct 22 2010 00:00:00 GMT-0500 (Central Daylight Time)
This looks to me like midnight on the following day. I have no idea why it's interpreting this as midnight, or at any rate why it's interpreting this differently than the default Date.parse in javascript. Am I confused over the meaning of 12:00 PM? Am I misusing date.js's parseExact?
Looks like a version issue:
http://jsfiddle.net/4QK8Q/
http://jsfiddle.net/JKg3n/
The first one is your file (from the google code base), the second is from their website (datejs.com). Funnily enough they look like the same version, but obviously aren't. I'm not familiar enough with the library to tell what's going on, but I suggest filing a bug report.
This is a fairly old question, but for those who may stumble upon this in a search, it's highly suggested that you switch to the currently maintained version of Date.js (https://github.com/abritinthebay/datejs/) if you're encountering unexpected behavior.
The versions on the Google code base and datejs.com both have unfixed bugs that are unlikely to ever be addressed, as the original developer seems to have abandoned the project.