Javascript Дата выпуска вопросов, возвращающихся на 1 день меньше установленной даты - часовой пояс

Question

Форматирование даты с Javscript Date().

Справочная информация: Я изменяю дату JQuery UI и получаю проблемы с месяцами и датами, возвращающими неправильные значения.

$('#datefield').datepicker({ 
    beforeShowDay: function(date) { 
     // issues experienced here - isolation test code below 
     // Mon Aug 01 2016 00:00:00 GMT+1000 (AUS Eastern Standard Time) 
     // DateMonth: 8 - ISO: 20160731 
    } 
}) 

Based JS Date() строительство на http://www.w3schools.com/jsref/jsref_obj_date.asp

Пример кода:

var d1 = new Date(); 
var d1Month = d1.getMonth()+1; 
var d1ISO = d1.toISOString().slice(0,10).replace(/-/g,""); 

console.log(d1); 
console.log('1Month: '+d1Month+' ISO: '+d1ISO); 

var d2 = new Date(2016,06,31); 
var d2Month = d2.getMonth()+1; 
var d2ISO = d2.toISOString().slice(0,10).replace(/-/g,""); 

console.log(d2); 
console.log('2Month: '+d2Month+' ISO: '+d2ISO); 

var d3 = new Date('2016-07-31'); 
var d3Month = d3.getMonth()+1; 
var d3ISO = d3.toISOString().slice(0,10).replace(/-/g,""); 

console.log(d3); 
console.log('3Month: '+d3Month+' ISO: '+d3ISO); 

var d4 = new Date(2016, 07, 01); 
var d4Month = d4.getMonth()+1; 
var d4ISO = d4.toISOString().slice(0,10).replace(/-/g,""); 

console.log(d4); 
console.log('4Month: '+d4Month+' ISO: '+d4ISO); 

Output (консоли):

Wed Aug 24 2016 11:30:51 GMT+1000 (AUS Eastern Standard Time) 
1Month: 8 ISO: 20160824 

*Sun Jul 31 2016 00:00:00 GMT+1000 (AUS Eastern Standard Time) 
2Month: 7 ISO: 20160730 

Sun Jul 31 2016 10:00:00 GMT+1000 (AUS Eastern Standard Time) 
3Month: 7 ISO: 20160731 

*Mon Aug 01 2016 00:00:00 GMT+1000 (AUS Eastern Standard Time) 
4Month: 8 ISO: 20160731 

Почему возвращение 'Д2' 20160730, когда объект возвращается 31 июля?

Почему «d4» возвращается 20160731, если дата установлена ​​1 августа?

Почему d3 работает правильно?

Мое предположение заключается в том, что дата ISO как-то вычитает GMT + 10 и получает предыдущий день.

Я Осознавая этот шаг (Protoype функция), чтобы попробовать и формат Get String in YYYYMMDD format from JS date object? , но его до сих пор для меня загадка, почему выше производит разные результаты ...

return [this.getFullYear(), !mm[1] && '0', mm, !dd[1] && '0', dd].join(''); 

Answer 1

Почему " d2 'return 20160730, когда объект возвращается 31 июля?

Потому что, когда вы делаете:

var d2 = new Date(2016,06,31); 

создание дату, эквивалентный 31 июля 2016 года в 00:00:00 в текущем часовом поясе своей системы. Когда вы делаете:

console.log(d2); 

текущие настройки системы используются для создания строки во временной зоне своей системы (по-видимому GMT + 10: 00) и будет показывать эквивалент 2016-07-31T00: 00: 00 +10: 00.

Но когда вы делаете:

console.log('2Month: '+d2Month+' ISO: '+d2ISO); 

дата в часовом поясе GMT ​​или 10 часов раньше, поэтому если время до 10:00, то дата будет предыдущий день (GMT) и вы увидите:

2016-07-30T14:00:00Z 

, но поскольку вы отрезали часть времени от строки, вы видите только часть даты.

Он «работает» для d3, потому что когда вы делаете:

var d3 = new Date('2016-07-31'); 

строка дата рассматривается как UTC *, так что вы создаете дату 2016-07-31T00: 00: 00Z который эквивалент 2016-07-31T10: 00: 00 + 10: 00, т.е.дата UTC совпадает с вашей локальной датой. Обратите внимание, что выход:

console.log(d3); 

находится в 10:00:00 (потому что встроенный ToString считает часовой пояс системы, так добавляет 10 часов в указанный день), что часовой пояс смещение.

Во всем вышеизложенном фактическое значение времени объекта Date - UTC. Смещение временного пояса хост-системы используется для создания значения времени изначально, для получите и методы для года, месяца, дня, часа и т. Д. (Поскольку переход на летнее время изменяет часовой пояс) и при создании понятных для человека строки даты.

* Обратите внимание, что это противоречит ISO 8601, в котором указано, что даты без компонента времени должны рассматриваться как локальные. Но ECMA-262 рассматривает их как UTC. Существуют определенные версии браузеров, где «2016-07-31» будет считаться недействительным, а другие, где он будет рассматриваться как локальный, а последний будет рассматривать его как UTC. Вот почему сильно рекомендуется всегда вручную анализировать строки даты (использовать свою собственную функцию или библиотеку с помощью синтаксического анализатора), чтобы вы контролировали, как она анализируется и как применяется часовой пояс.