JavaScript Date() returns the wrong time

Question

My simple test:

var ds = "2018/2/28 15:59";
console.log(ds);
var da = Date(ds);
console.log(da);
ds = "2018-2-28 15:59";
console.log(ds);
var da = Date(ds);
console.log(da);

The results are

2018/2/28 15:59  
Thu Feb 01 2018 17:26:57 GMT+0800 (+08)  
2018-2-28 15:59  
Thu Feb 01 2018 17:26:57 GMT+0800 (+08)

Even given the time "2018/2/28 15:59" is in a different time zone, it is still very puzzling as the minutes and seconds are different: 59:00 versus 26:57. Timezone differences are in multiples of 30 minutes.

Why don't you use "new Date(...)" instead of just "Date(...)"? https://www.w3schools.com/jsref/jsref_obj_date.asp https://www.w3schools.com/js/js_dates.asp — D. Braun, Feb 01 '18 at 09:40
Notice how the date is wrong too. Your argument is being ignored and you would get the same result from a plain `Date()`. (`Date()` acts differently when not used as a constructor, like in `new Date()`. The latter isn’t guaranteed to parse many formats either, though, so just avoid it entirely.) — Ry-, Feb 01 '18 at 09:40
Why don't you use moment.js for parsing and dormatting Dates: https://momentjs.com/ — D. Braun, Feb 01 '18 at 09:41
Regarding "*Timezone differences are in multiples of 30*", not necessarily. Some are 15 or 45 minutes, e.g. Nepal Standard Time is UTC+05:45 and Chatham Standard Time is UTC+12:45. Once you add "new", your next question will be answered by [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) — RobG, Feb 01 '18 at 12:38

flx · Answer 1 · 2018-02-01T12:59:20.530

6

You forgot to add new before Date().

This means you were just calling a function called Date() which (by default) retuns the current date and time.

var ds = "2018/2/28 15:59";
console.log(ds);
var da = new Date(ds);
console.log(da);
ds = "2018-2-28 15:59";
console.log(ds);
var da = new Date(ds);
console.log(da);

An addition to AuxTacos answer, the proper way to init. your date:

var da = new Date(2018, (2-1), 28, 15, 59); // x-1 because 0=Jan,1=Feb...
console.log(date);

edited Feb 01 '18 at 12:59

answered Feb 01 '18 at 09:38

flx

1,560
13
22

1

[MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#Description): "Invoking JavaScript Date as a function (i.e., without the new operator) will return a string representing the current date and time." – Álvaro González Feb 01 '18 at 09:44
1

The second parameter for the "proper way" should be 1 (for February), not 2 (which is March). ;-) – RobG Feb 01 '18 at 12:42
@RobG thanks. Ive displayed it a little bit different to show better **why**. – flx Feb 01 '18 at 12:59

AuxTaco · Answer 2 · 2018-02-01T21:29:40.847

3

In addition to zeropublix's answer (you forgot the new), your date strings are invalid. The proper way to encode "15 hours and 59 minutes past the midnight marking the beginning of the 28th day of February, 2018 CE" is "2018-02-28T15:59Z". Your system (and mine) might recognize "2018/2/28 15:59" as a valid date string, but that's implementation-dependent and prone to failure. The only format recognized in the specification is a simplification of ISO 8601.

edited Feb 01 '18 at 21:29

answered Feb 01 '18 at 10:04

AuxTaco

4,883
1
12
27

3

And you can also provide each piece of data as a separate argument and avoid all possible ambiguity but, for some reason, it isn't as popular as strings. – Álvaro González Feb 01 '18 at 10:06
Even some current browsers will not correctly parse "2018-02-28T15:59", the built-in parser should not be used (e.g. Safari 11 treats it as UTC, not local). – RobG Feb 01 '18 at 12:45
That's correct behavior according to the spec and should be reliable. Granted, it's not ISO 8601 spec, but it's still well-specified. – AuxTaco Feb 01 '18 at 13:30
@AuxTaco—your comment is ambiguous to me. ISO 8601 extended format without a timezone should be parsed as local according to ECMA-262 (which is consistent with ISO 8601), but Safari get's it wrong, which is further evidence that built-in parsers are unreliable. – RobG Feb 01 '18 at 20:33
@RobG From ECMA-262, 5.1 Edition: "ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ", "Z is the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression HH:mm", "The value of an absent time zone offset is “Z”." – AuxTaco Feb 01 '18 at 21:20
Aaaand in version 8, "When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time." ...Neat. Including the time-zone offset should still make it unambiguous. – AuxTaco Feb 01 '18 at 21:25
@AuxTaco—yes it should, but there are cases where you don't want to include an offset. Date-only formats especially should be treated as local, the last two systems I developed did not want date-only treated as UTC, so we had to implement special date handling because of the crazy TC39 decision to treat them as UTC. Sorry, bit of a sore point… – RobG Feb 02 '18 at 00:43

score -1 · Answer 3 · answered Feb 01 '18 at 09:42

-1

I try this.

var ds = "2018/2/28 15:59"; 
var da = new Date(ds);

it gives me Date 2018-02-28T15:59:00.000Z. I got right time and date.

answered Feb 01 '18 at 09:42

Noriel

218
1
7

score -1 · Answer 4 · answered Feb 01 '18 at 09:49

-1

var da = Date(ds); here Date gives the current time even if you pass parameter.

try this.

var ds = "2018/2/28 15:59"; var da = new Date(ds);

which gives 2018-02-28T10:29:00.000Z

answered Feb 01 '18 at 09:49

Chandrika

194
12

Parsing of a string like "2018/2/28 15:59" is implementation dependent and may or may not produce a Date equivalent to "2018-02-28T10:29:00.000Z". The one I'm currently using doesn't, `new Date("2018/2/28 15:59").toISOString()` returns "2018-02-28T05:59:00.000Z", others might give an invalid Date. :-( – RobG Feb 01 '18 at 12:48

JavaScript Date() returns the wrong time

4 Answers4