This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 6 years ago.
I was trying to check what values would return if partial values are sent.
var d = new Date("11/28");
console.log(d.toLocaleDateString())
I was expecting it to be 28th Nov., 2016(current year), but it returns 28th Nov., 2001.
So the question is Why is 2001 considered as default year?
2001 is not consider as default year.
This is a Chrome issue, if you run the same code with Firefox you get Invalid Date.
The language specification only includes rules for parsing ISO 8601 formatted strings. Parsing of any other format is implementation dependent (noting that the Date constructor and Date.parse are equivalent for parsing).
So given "11/28" is not a valid ISO 8601 string, the implementation is free to apply any heuristics it likes. Any result, including an invalid date, should be expected and consistency between implementations should not.
Related
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
How to validate a date?
(11 answers)
Closed 2 years ago.
I've seen many articles about this but not quite found what I am looking for yet.
I'm trying to simply check if a string is a date. That string might contains a number such as 2012 though.
var timestamp = Date.parse('foo 2012');
if (isNaN(timestamp) == false) {
var d = new Date(timestamp);
console.log('DATE', d)
}else{
console.log('TEXT');
}
//OUTPUT: DATE Sun Jan 01 2012 00:00:00 GMT+1100 (Australian Eastern Daylight Time)
Why does javascript convert foo 2012 into a date when it's clearly not?
How can I validate that my string is an actual date ?
A string is never a date.
A string can represent a date. There are many ways to represent the same date through different string formats.
This means "validating that a string is a date" is an impossible task. What you can do instead is:
Validate that the format of the string conforms to some well-known format and that its contents are valid.
Try to parse a given string as an expected format and either throw an error or return a "guard" value to indicate that the parsing was not a success.
JavaScript took a third option, which is like option 2, only it returns a value indicating its "best efforts" at working with the garbage input. That's apparently why it saw a year in your string and decided "well, I guess I can make a date with this?" As #Pointy pointed out, it's actually in the spec that if the JavaScript string doesn't match one of the two supported formats, the implementer can decide what the result should be.
I'd highly recommend that if you're dealing with date strings, you should stick with a consistent format. I'm a big fan of ISO 8601 date/time strings because they are time zone aware, easy to sort, and are widely supported (including being easily parsed by JavaScript). If you're requiring the strings are in a standard format, it's easier to do things like finding A RegExp that can validate the input.
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 3 years ago.
Trying to get UTC day of the week for any given timestamp on any given machine (w/ their own local time) I used:
var date = new Date(timestamp).toLocaleString('en-GB', { timeZone: 'UTC' });
Once I try to convert the date string to UTC date I get Invalid Date for some dates... it all seems pretty weird.
$ node
> date = new Date('15/08/2019, 00:00:00');
Invalid Date
> date = new Date('12/08/2019, 00:00:00');
2019-12-08T00:00:00.000Z
> date = new Date('15/08/2019');
Any idea where the Invalid Date issue may come from?
By converting the timestamps to strings using the "en-GB" locale, it looks like you're getting them in DD/MM/YYYY format. But in your second example, the strings are being interpreted as "MM/DD/YYYY" in whatever your default locale is, so the first call fails because 15 isn't a valid month number.
This question already has answers here:
Javascript Date.UTC() function is off by a month?
(4 answers)
Closed 5 years ago.
I get dates from server as a list, for example, [2017,8,24,9,0]. When I parse and localize them in momentjs, all the dates are one month ahead: instead of August, I get September. In case of [2017,8,31,9,0], I get invalid date.I think it is because September is not 31 days.
My question is how to parse dates such as [2017,8,24,9,0], [2017,8,29,20,0], and [2017,8,31,9,0] into D.MMM [kl.] H:mm format?
I understand that JavaScript date is zero-indexed while java date isn't. I have used momentjs subtract() method, but [2017,8,31,9,0] is still invalid date.
That's a javascript issue. But is not a bug. In js dates, months are zero based. It is, 0 = january, 1 = february, etc. To solve this you can subtract the month by 1.
var myServerDate = [2017,8,24,9,0];
myServerDate[1] = myServerDate[1] -1;
Then you can proceed with the parsing process.
This question already has answers here:
different result for yyyy-mm-dd and yyyy/mm/dd in javascript when passed to "new Date" [duplicate]
(2 answers)
Closed 6 years ago.
I am using Date.parse to convert a string to a date in javascript, however, if the string looks like this '10/11/2016' it is interpreted as Oct 11 2016, i need it to be interpreted as Nov 10 2016
Suggestions?
By default Date.parse consider in this format that month precede the day to be in your case MM/DD/YYYY not as you want DD/MM/YYYY.
I prefer/suggest using 3rd party date parser library as Moment.js
It can take your date-string and the format to be like this:
moment("10/11/2016", "DD-MM-YYYY");
This question already has answers here:
JavaScript's getDate returns wrong date
(12 answers)
Closed 6 years ago.
This is so basic, but it makes no sense to me:
new Date("2010-01-01").getFullYear();
result: 2009
wth? My goal is to reformat the date as mm/dd/yyyy given the format yyyy-mm-dd..
Adding on:
new Date("2010-01-01").getMonth();
result: 11
new Date("2010-01-01").getDate();
result: 31
The date string you're passing into new Date() has no timezone in it. It's being interpreted as UTC. The critical thing to understand here is that a Date is stored as a Unix timestamp (seconds since 1970-01-01 00:00, making 'Date' a misleading name) so if you don't specify the time within the date, it's going to apply a default.
Date.prototype.getFullYear() retrieves the full year for that timestamp in your LOCAL time. (See the docs here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getFullYear)
You're somewhere west of UTC, and 2010-01-01 UTC is 2009-12-31 in your local time.
And for your final mystery....getMonth() is 0-based, not 1-based, so '11' is December.
Don't use the Date constructor to parse strings, it's largely implementation dependent and inconsistent.
An ISO 8601 date and time without a timezone like "2016-02-29T12:00:00" should be treated as local (i.e. use the host system timezone offset to create a Date), but a date–only string is treated like "2016-02-29" as UTC. The first behaviour is consistent with ISO 8601, but the second isn't.
Some versions of browsers will treat date–only strings as UTC, and some as invalid dates, so always parse strings manually (a two line function or library can help). That way you know how it will be parsed in all hosts.
Provide Time with date in the new Date() as parameter . Then u will get exact Result.