2

I have an angular.js application, and I want to get the dates of Monday and Sunday of the current week, which are then set to calendar dates by default. I was looking at an error due to the produced dates not falling within 7 days time span. I fixed the issue.

But as I was playing around with the code I found out that, similar date creation code was producing different values for hour. Here is a snippet of my code:

var current = new Date(); // get current date    
var weekstart = current.getDate() - current.getDay() + 1;
var weekend = weekstart + 6; // end day is the first day + 6 
var firstday = new Date(current.setDate(weekstart));
firstday = new Date(firstday.getFullYear() + '-' + (firstday.getMonth() + 1)
                    + '-' + firstday.getDate());
console.log("Monday: " + firstday);

//firstday.setHours(0, 0, 0, 0);
var last = new Date(firstday);
last.setDate(last.getDate() + 6);
console.log("Sunday 1: " + last);
var lastday = new Date(last.getFullYear() + '-' + (last.getMonth() + 1)
                       + '-' + last.getDate());
console.log("Sunday 2: " + lastday);

Here are the values generated in my console:

Monday: Mon Oct 09 2017 00:00:00 GMT+1100 (AUS Eastern Daylight Time)
Sunday 1: Sun Oct 15 2017 00:00:00 GMT+1100 (AUS Eastern Daylight Time)
Sunday 2: Sun Oct 15 2017 11:00:00 GMT+1100 (AUS Eastern Daylight Time)

Why is the Hour field in Sunday 2 getting generated as 11, whereas similar new Date call for Monday resulted in 00?

nnnnnn
  • 147,572
  • 30
  • 200
  • 241
roshan
  • 323
  • 8
  • 22
  • 2
    No idea why this is happening but maybe you could use the `new Date(year, month, date)` constructor instead to avoid the ambiguity. – H77 Oct 10 '17 at 02:03

2 Answers2

3
new Date('2017-10-9')
2017-10-08T16:00:00.000Z
> new Date('2017-10-15')
2017-10-15T00:00:00.000Z
> new Date('2017-10-09')
2017-10-09T00:00:00.000Z

The difference is assumed timezone.

2017-10-09 assumes UTC timezone, while 2017-10-9 assumes local timezone.

Differences in assumed time zone Given a date string of "March 7, 2014", parse() assumes a local time zone, but given an ISO format such as "2014-03-07" it will assume a time zone of UTC (ES5 and ECMAScript 2015).

In my case, timezone is +8, so the time differs 8 hours. In your case, it's +11.

Check https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse for more details

banyudu
  • 1,046
  • 9
  • 19
  • 1
    But the text you quote is talking about a date string format that the OP isn't using. The difference in the input with this question's code is `9` versus `09` for the date - why would that affect the time in the output? – nnnnnn Oct 10 '17 at 02:07
  • 1
    @nnnnnn Date.parse() assumes different timezone for different dateString format. – banyudu Oct 10 '17 at 02:09
  • 1
    yup. it says **This means that two date strings that appear equivalent may result in two different values depending on the format of the string that is being converted.** – roshan Oct 10 '17 at 02:10
  • @YuduBan To get the date in local and UTC time for 2 digit dates. This is strange. `new Date("2017-10-019");` **Thu Oct 19 2017 00:00:00 GMT+1100 (AUS Eastern Daylight Time)** `new Date("2017-10-19");` **Thu Oct 19 2017 11:00:00 GMT+1100 (AUS Eastern Daylight Time)** – roshan Oct 10 '17 at 02:21
  • @roshankrishnan It depends on the details of v8 date-parser, but I'm not familiar with it. Just a guess, date-parser may treat format '2017-10-19' as UTC time, while others will be sperated into 3 digits, and use local timezone. – banyudu Oct 10 '17 at 02:42
-1

Read this

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.

Bryce Zhou
  • 44
  • 4