Правильный формат ISO 8601
Вопрос
Я занимаюсь рефакторингом некоторого кода для библиотеки Ruby.Этот код включает в себя анализатор дат.Одним из тестов был анализ этой строки "2008-02-20T8: 05: 00-010: 00", которая должна быть ISO 8601.
Предыдущий код фактически выводил бы:"Ср. 20 февраля 18:05:00 UTC 2008".Мой новый код выводит следующее:"Ср. 20 февраля 16:05:00 UTC 2008".
Мой вопрос заключается в следующем:какой из них правильный?
Time.parse
в Ruby дается второй вариант.Но опять же, я хочу быть на 100% уверен, что предыдущий код И тест были глючными.
Какой из них правильный?(Возможно, путем синтаксического анализа строки с помощью библиотеки на другом языке?- Я знаю только Руби.)
Решение
Правильное время по Гринвичу - 1805.Временная группа указывает 0805 в зоне -10, поэтому, чтобы получить UTC, добавьте 10 к заданному времени.Итак, 1805 год.Поскольку 1805 - это меньше 2400, это один и тот же день.
Если ваш код выдает 1605, то вы почти наверняка неправильно установили часовой пояс на зону -8, которая соответствует тихоокеанскому стандартному времени.
Ага, похоже, у вас перепутан формат ввода.Наблюдать:
irb(main):003:0> Time.parse("2008-02-20T8:05:00-010:00")
=> Wed Feb 20 08:05:00 -0700 2008
Так случилось, что я нахожусь в зоне -7, так что это соответствует моему местоположению.Но
irb(main):004:0> t=Time.parse("2008-02-20T8:05:00-010:00")
=> Wed Feb 20 08:05:00 -0700 2008
irb(main):005:0> t
=> Wed Feb 20 08:05:00 -0700 2008
irb(main):006:0> t.getutc
=> Wed Feb 20 15:05:00 UTC 2008
Я получаю неожиданный результат.Теперь наблюдайте:
irb(main):007:0> t=Time.parse("2008-02-20T8:05:00-10:00")
=> Wed Feb 20 11:05:00 -0700 2008
irb(main):008:0> t.getutc
=> Wed Feb 20 18:05:00 UTC 2008
Там есть ожидаемый Результат.Видите разницу?Первый пример против второго:
irb(main):004:0> t=Time.parse("2008-02-20T8:05:00-010:00")
irb(main):007:0> t=Time.parse("2008-02-20T8:05:00-10:00")
Я убрал поддельный дополнительный 0 (который Я конечно, тоже не заметил) и вжик, это работает.
Другие советы
Я знаю, что это довольно старое сообщение, но я только что наткнулся на него.
Держу пари, что что-то где-то интерпретирует 010
в качестве восьмеричное число число со значением 8.Возможно, это ошибка в реализации Time.parse()
?