javascript неправильно определяет временную шкалу перехода на летнее время — пример из 2006 года
Я прочитал много вопросов StackOverflow по объекту javascript new Date(), когда речь идет о строках перехода на летнее время --. как в случае их пересечения. Однако я не видел ответа об этой конкретной проблеме или способе ее решения, пока все еще полагался на «время unix».
Я лично решил обойти эту проблему, передав дату javascript в качестве даты моему PHP-коду, а не время unix. И все же остается животрепещущий вопрос! Я подтвердил это поведение в IE8, Chrome и FF, поэтому я предполагаю, что оно будет вести себя так же для вас.(Обновление:Пользователи OSX могут не генерировать такое поведение)
Мое исследование; самые близкие вопросы к моему вопросу:
- Этот пользователь работал в определенные часы перед переходом на летнее время.
- Этот пользователь беспокоился о представлении времени в зависимости от часового пояса пользователя. В принятом ответе на этой странице упоминалось, что
getTimezoneOffset«ненадежный», что заставило меня не вникать в это. - См. мой ответ ниже на другие вопросы, которые имеют некоторые важные идеи
Я создал тестовый сценарий примерно 1 ноября 2006 года. Это может сработать или не сработать для вас в зависимости от часового пояса, в котором вы находитесь. Если я правильно понимаю аспект javascript, вам нужно будет синхронизировать часы вашего ПК с
Eastern Time (US & Canada) and check the 'Automatically adjust clock for Daylight Saving Time'.
Я основываю этот эксперимент на часовом поясе «Индианаполис» в PHP. Мой результат javascript, когда я обнаружил, что время unix на 1 ноября 2006 года составляет один час от того, что PHP генерирует (3600 секунд ). Согласно этой странице(Спасибо, Джон! )JavaScript неверен.
Результаты на двух языках снова согласованы 06.11.2006!
Это и другие исследования заставляют меня поверить, что Javascript неправильно понял свою историю и выбрал неправильное воскресенье для «отката» из летнего времени --, тем самым вызвав несоответствие, которое я вижу.
Я попытался максимально упростить это, но в движении все еще довольно много шестеренок.
1)Вот код PHP и вывод , который показывает ПРАВИЛЬНОЕ количество миллисекунд до даты 01.11.2006.
date_default_timezone_set("America/Indiana/Indianapolis");
echo "Unixtime for November 1, 2006 is: ".strtotime("11/01/2006")."\n";
echo "Unixtime for November 6, 2006 is: ".strtotime("11/06/2006");
Результат:
Unixtime for November 1, 2006 is: 1162357200 (where the disagreement lies)
Unixtime for November 6, 2006 is: 1162789200
Оба они основаны на GMT -0500.
2 )В Javascript (см. мой jsfiddle**), я вызываю new Date, а затем getTime()вот так (и удаляю миллисекунды):
new Date("2006/11/01").getTime()/1000
new Date("2006/11/06").getTime()/1000
Это генерирует значения
1162353600 <-- PHP outputs: 1162357200
1162789200 <-- the same as PHP for '2006/11/06'; congruence is restored
что является разностью(за 01.11.2006 )из вывода через PHP 3600 секунд --или один час. Это значение (на час раньше )при обработке в моем PHP-приложении сгенерировало предыдущий день (31.10.2006 ), что было неприемлемо, поскольку оно нарушало мою навигацию вперед.(см. дополнительные пояснения к моему конкретному сценарию)
Вывод в Javascript:Date("2006/11/01")без вызова getTime()проясняет часть загадки, потому что javascript показывает смещение, которое он использовал GMT-0400.
Мой jsfiddle**эксперимент (, также упомянутый выше ), показывает эти результаты.
**(вам может потребоваться изменить часовой пояс вашего компьютера, чтобы увидеть идентичное поведение ).
Возможно, в игру вступает то, что согласно Википедии 2006 год был первым годом, когда Индиана начала использовать летнее время. Любопытная головоломка в любом случае.
Поскольку я уже разработал свое решение (, не полагаясь на время unix в моем javascript ), я подумал, что должен опубликовать это для потомков, и, надеюсь, кто-то может знать, как исправить значение, которое показывает javascript.
Вопрос вот в чем:Как привести два результата «время unix» между PHP и javascript в соответствие? Я был бы признателен, если бы узнал, как обойти «линию» DST или вообще. (В настоящее время я предполагаю, что проблема связана со строкой перехода на летнее время ).
Обновление:iMac под управлением Chrome сгенерировал результаты, которые генерирует PHP. Что??? Дикий. Любое стороннее исправление этого поведения с помощью javascript -выглядит так, как будто оно было бы отличным делом (или, по крайней мере, уродливым ). Возможно, это не является проблемой javascript, поскольку он генерирует правильный ответ в зависимости от ОС (или других факторов? ).
Примечательно, что на этом iMac я не не задавал часовой пояс, и я не уверен, что этот компьютер Apple позволит это сделать. Настройки для «Автоматическая установка даты и времени» были проверены(true)и disabled. Часовой пояс был установлен на восточное летнее время. Флажок «Установить часовой пояс автоматически» был снят (false). и disabled.
Я добавил тег Windows, чтобы подчеркнуть, что это не проблема в OSX.
Обновление:Согласно сайту , указанному выше , я проверил, что все следующие даты пересекаются с новым смещением по Гринвичу в соответствующие даты (обновленная скрипка)--в отличие от того, как ответ 2006 года был одной неделей . То есть 4 ноября 2007 года это было GMT-4и 5 ноября 2007 года оно вернулось GMT-5.
- 2007 Воскресенье, 11 марта, 2 :00 утра Воскресенье, 4 ноября, 2 :00
- 2008 Воскресенье, 9 марта, 2 :00 утра Воскресенье, 2 ноября, 2 :00
- 2009 Воскресенье, 8 марта, 2 :00 утра Воскресенье, 1 ноября, 2 :00
- 2010 Воскресенье, 14 марта, 2 :00 утра Воскресенье, 7 ноября, 2 :0000
- 2011 Воскресенье, 13 марта, 2 :00. Воскресенье, 6 ноября, 2 :00
Наконец,если вы знаете надлежащие каналы для отправки этой ошибки в 2006 году в любой источник часового пояса, на который полагается Javascript, сделайте это и дайте мне знать об этом.