При реализации задачи таймера обратного отсчёта столкнулся с одним «сюрпризом», а именно методом 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 или других?