Я заметил следующее странное поведение метода toTimeString
.
const date1 = new Date("2022-09-23T00:00:00.00Z")
const date2 = new Date()
date1.toTimeString()
//17:00:00 GMT-0700 (Pacific Daylight Saving Time)
date2.toTimeString()
// 15:06:43 GMT-0800 (Pacific Standard Time)
Я также заметил, что результат для date1
зависит даже от настроек региона устройства (по крайней мере, для Mac)
date1.toTimeString()
// if region is set to Canada
// 17:00:00 GMT-0700 (Pacific Daylight Saving Time)
// if region is set to United States
// 17:00:00 GMT-0700 (Pacific Daylight Time)
Еще одно наблюдение
date2.toTimeString()
// this is the result for both United States and Canada
// 15:06:43 GMT-0800 (Pacific Standard Time)
Пара вопросов
Почему результат зависит от того, как построена дата?
(new Date("2022-09-23T00:00:00.00Z")
против new Date
)
Для new Date("2022-09-23T00:00:00.00Z")
, почему результат зависит от настройки устройства?
Результат кажется последовательным, когда аргументы не передаются, например new Date()
. Можем ли мы предположить, что это создаст согласованное имя часового пояса независимо от настроек устройства?
Примечание. Я также заметил такое же поведение с date-fns-tz
Обновлено: добавлен еще один пример выше.
Другой вопрос:
4.В отличие от вопроса 2, new Date().toTimeString()
не зависит от настроек региона. Почему это так
Обновлено еще раз: Я понял это.
Для стран с дневным светом. Поведение toTimeString()
будет создавать разные часовые пояса в зависимости от того, когда попадает временная метка.
Оставьте эту тему здесь, так как она может быть полезна другим
В первом случае вы вызываете конструктор Date со строковым представлением даты 2022-09-23
со временем 00:00:00 (GMT offset 0)
, и он возвращает экземпляр объекта Date для 23.09.2022 00:00:00. Во втором случае вы вызываете пустой конструктор Date, который возвращает экземпляр объекта Date с текущей датой и временем.
Затем, когда вы вызываете метод toTimeString()
, он возвращает временную часть объекта Date, интерпретируемую в местном часовом поясе (подробнее см. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects). /Date/toTimeString).
Если вы хотите получить название местного часового пояса, смотрите здесь Как я могу получить название часового пояса в JavaScript?
@tpszhao — летнее время в США в 2022 году было с 13 марта по 6 ноября. Одна дата — 22 сентября (PDT), когда соблюдается летнее время, а другая — 19 ноября (PST), когда это не так.
- Почему результат зависит от того, как построена дата? (новая дата ("2022-09-23T00:00:00.00Z") по сравнению с новой датой)
Временная метка «2022-09-23T00:00:00.00Z» анализируется с нулевым смещением из-за завершающей буквы «Z». Это фактически делает его UTC.
Вызов new Date()
создает экземпляр Date для текущей даты и времени. toTimeString возвращает время, которое представляет экземпляр Date на основе системных настроек. Таким образом, для данного экземпляра, если вы измените местоположение в настройках системы на место с другим смещением, вы получите другое время.
Если региональные настройки предназначены для места, в котором соблюдается летнее время (DST), вы также получите другое смещение (и название гражданского часового пояса) для дат в то время года, когда действует и не действует летнее время.
- Для новой даты ("2022-09-23T00:00:00.00Z"), почему результат зависит от настройки устройства?
Созданный экземпляр Date абсолютно одинаков независимо от системных настроек, поскольку смещение фиксируется как 0 в метке времени. Результат toTimeString зависит от системных настроек, потому что именно оттуда он получает информацию о смещении хоста и названии гражданского часового пояса.
- Результат кажется последовательным, когда аргументы не передаются, например, new Date(). Можем ли мы предположить, что это создаст согласованное имя часового пояса независимо от настроек устройства?
Нет. Имена часовых поясов не стандартизированы и зависят от реализации в соответствии с ECMA-262. Однако фактическое смещение должно быть постоянным.
Предлагаю прочитать Почему Date.parse выдает некорректные результаты? для фона.
Поскольку
toTimeString
интерпретируется в местном часовом поясе, то не должно ли оно быть согласованным независимо от того, как построена дата? ака почему одинGMT-0700
а другойGMT-0800