При реализации задачи таймера обратного отсчёта столкнулся с одним «сюрпризом», а именно методом getTimezoneOffset, который отдавал то 3 часа, то 4 часа разницы. Этим хотел бы и поделиться.
В данном случае погрешность setInterval настолько мала, что ей можно было пренебречь.
Реализация самой задачи:
(function init() {
var date1 = new Date("Jan 1, 1970"),
date2 = new Date("Jan 1, 1970"),
timezoneOffset = new Date().getTimezoneOffset(),
$days = $('.timestamp .days .number'),
$hours = $('.timestamp .hours .number'),
$minutes = $('.timestamp .minutes .number');
date1.setMinutes(-timezoneOffset);
date2.setMinutes(-timezoneOffset);
date2.setUTCSeconds(60);
var timer = setInterval(function() {
$days.text( parseInt(date2.getTime()/1000/60/60/24) );
$hours.text( date2.getUTCHours() );
$minutes.text( date2.getUTCMinutes() );
date2.setUTCSeconds( date2.getUTCSeconds()-1 );
if (date1.toUTCString() === date2.toUTCString()) {
clearInterval(timer);
}
}, 1000)
})()
Вскоре обнаружил баг, когда в IE оставалось меньше часа, но в счётчике выводилось 1 час, в то время как в других браузерах — нормально.
Вся проблема оказалось в этом:
timezoneOffset = new Date().getTimezoneOffset(),
Итак, попробуем получить смещений временной зоны:
new Date('1 Jan, 1970').getTimezoneOffset();
Получаем смещение в 240 минут;
В IE при выполнении того же кода мы получаем смещение по временной зоне уже в 3 часа.
Посмотрим что вернёт нам IE в случае года, близкого к текущему:
new Date('1 Jan, 2012').getTimezoneOffset():
//-240
new Date('1 Jan, 2011').getTimezoneOffset();
//-180
Ошибка в коде возникала по причне того, что для кода
new Date("Jan 1, 1970"),
мы получаем смещение на 3 часа, а для
new Date().getTimezoneOffset()
уже на 4 часа.
Полагаю, что здесь учитывается то, чем занимается Россия в последнее время — перевод стрелок.
Какой же подход тут правилен: IE или других?
Автор: jaybekster