Почему необходимо иметь информацию о дневном свете в файлах iCal
Я хочу понять, почему обязательно предоставлять информацию о дневном свете в сгенерированных нами файлах. Почему не хватает времени по Гринвичу / UTC и почему почтовый клиент, такой как MS Outlook 2010, не справится с этим.
2 ответа
Основная причина заключается в том, что на компьютере может существовать или отсутствовать часовой пояс, соответствующий TZID указано. iCAL позволяет идентификаторы часовых поясов любого типа, включая часовые пояса IANA, например "America/Bogota" и часовые пояса Windows, такие как "SA Pacific Standard Time",
Информация о часовом поясе в системе, указанной в TZID, должна быть предпочтительной, когда она доступна, но она может быть недоступна. Кто-то может посмотреть на файл iCal, созданный на компьютере с Windows во время работы на Mac. Либо может быть не все текущие обновления часового пояса, а TZID может относиться к вновь созданному часовому поясу, который еще не установлен на машине.
Кодирование правил в файл iCAL необходимо для обеспечения взаимодействия. Недостатком этих правил является то, что они фиксируются на их известных значениях с момента создания события. Если правила изменятся до того, как событие произойдет, событие может произойти не в то время - в зависимости от того, как файл был интерпретирован. Вот почему лучше использовать информацию в системе, когда у вас есть совпадение по TZID.
Что касается того, почему UTC недостаточно для планирования, то это потому, что события почти всегда указываются в терминах местного времени. Отношение местного времени к UTC сильно зависит от часового пояса, который устанавливается конкретным местным правительством. Они должны учитывать летнее время и другие аномалии, и правительства могут передумать.
Например, если повторяющаяся встреча была запланирована на 8:00 по местному времени каждый день в часовом поясе США в Тихом океане, в течение стандартного времени, которое должно было бы происходить в 16:00 по UTC, и в дневное время, это происходило бы в 5:00. PM UTC. Если бы вместо этого я планировал по UTC, то мое местное время было бы на час до или после перехода на летнее время. Это обычно называют "проблемой с будильником", и среди прочих было причиной ошибки iPhone DST 2010 года.
Я полагаю, что первоначальная цель спецификации iCalendar состояла в том, чтобы предоставить независимый формат файла, который будет одинаково интерпретироваться всеми агентами пользователя календаря (CUA), такими как Outlook. Поскольку вы не можете предполагать, что все CUA имеют одинаковую информацию о часовом поясе, она должна быть включена в формат файла.
В действительности, однако, часто более практично использовать встроенные определения часовых поясов, и в этом случае вы можете просто указать все значения времени в UTC (т. Е. С добавленной "Z")