Встреча сдвинулась на час? Проверьте часовую зону в файле .ics

Две повторяющиеся встречи могут начинаться в один момент, а после перевода часов разойтись. Проверьте, привязана ли серия к местному времени города или UTC, и сравните конкретные даты. Одна экспортированная встреча не раскрывает всё правило.

Автор Coru · Опубликовано 2026-10-23 · Обновлено 2026-10-23

Начните со встречи, которая сдвинулась

Еженедельный звонок 23 октября 2026 года стоит на 15:00 по Амстердаму. Через неделю календарь показывает 14:00. Прежде чем переносить его вручную, выясните, что должно сохраняться: 15:00 в Амстердаме, 09:00 в Нью-Йорке или постоянное время UTC. Это разные расписания.

Разберём две вымышленные серии с одинаковым первым моментом начала. Это проверка еженедельных встреч с указанным временем: загружать куда-либо календарь или личное приглашение не требуется.

Почему три пятницы отличаются

В Нидерландах часы переводят назад 25 октября 2026 года, с 03:00 на 02:00. В Нью-Йорке — 1 ноября, с 02:00 на 01:00. Переходы приходятся на разные выходные.

23 октября Амстердам живёт по UTC+02:00, а Нью-Йорк — по UTC−04:00. 30 октября это UTC+01:00 и UTC−04:00; 6 ноября — UTC+01:00 и UTC−05:00. Разница составляет сначала шесть, затем пять, затем снова шесть часов. Таблица относится именно к этим городам и датам: переносить её на любую страну или год нельзя.

Два правила, одна первая встреча

В файле iCalendar строка DTSTART задаёт начало. Параметр TZID ссылается на описание часовой зоны, а Z в конце означает UTC. Правило ниже задаёт три еженедельных начала, включая первое. Это поясняющие фрагменты, а не готовые файлы для импорта. Для варианта A предполагается корректное описание Europe/Amsterdam на эти даты.

A: сохранять 15:00 в Амстердаме

text

DTSTART;TZID=Europe/Amsterdam:20261023T150000
RRULE:FREQ=WEEKLY;COUNT=3

Местное время остаётся равным 15:00. Соответствующее время UTC может меняться.

B: сохранять 13:00 UTC

text

DTSTART:20261023T130000Z
RRULE:FREQ=WEEKLY;COUNT=3

Время UTC остаётся равным 13:00. Соответствующее время в Амстердаме может меняться.

Сравните получившиеся начала

В каждой строке указаны Амстердам / Нью-Йорк / UTC. Все три времени в строке обозначают один момент в указанную дату. Примеры рассчитаны в Coru с помощью Python zoneinfo; даты переходов 2026 года сверены с официальными источниками.

A, 23 октября: 15:00 / 09:00 / 13:00.
A, 30 октября: 15:00 / 10:00 / 14:00.
A, 6 ноября: 15:00 / 09:00 / 14:00.
B, 23 октября: 15:00 / 09:00 / 13:00.
B, 30 октября: 14:00 / 09:00 / 13:00.
B, 6 ноября: 14:00 / 08:00 / 13:00.

Две еженедельные серии в 2026 году. A сохраняет 15:00 в Амстердаме: в Нью-Йорке 09:00, 10:00, затем 09:00. B сохраняет 13:00 UTC: в Амстердаме 15:00, 14:00, затем 14:00, а в Нью-Йорке 09:00, 09:00, затем 08:00. — Три строки — 23 октября, 30 октября и 6 ноября 2026 года. Первые встречи совпадают. Выделенная строка находится между переводами часов в двух городах; исключений из повторения нет. Иллюстрация: Coru. Авторская схема Coru, рассчитанная для указанных часовых зон.

Прочитайте копию, не меняя её

Если у вас уже есть приглашение или экспорт в формате .ics, откройте копию через команду «Открыть» обычного текстового редактора. Двойной щелчок по файлу может вместо этого запустить импорт в календарь. Сохраните оригинал и проверяйте файл на своём устройстве.

Найдите нужное событие между BEGIN:VEVENT и END:VEVENT по названию (SUMMARY) и идентификатору (UID). В одном файле может быть несколько событий.
Внутри этого события посмотрите DTSTART и RRULE. Строка DTSTART внутри VTIMEZONE описывает переход часовой зоны, а не вашу встречу.
DTSTART с датой и временем, но без TZID и конечной Z задаёт «плавающее» время: оно не обозначает общий момент для разных часовых зон. События на весь день, где указана только дата, здесь не рассматриваются.
Если RRULE отсутствует, остановите это сравнение. Экспорт может содержать отдельную встречу или набор отдельных записей. Одна строка начала в UTC не доказывает, как повторяется исходная серия.

Проверьте серию целиком и зону отображения

В реальной серии RDATE может добавлять даты, EXDATE — исключать их, а отдельное событие с RECURRENCE-ID — изменять конкретную встречу. Такие исключения меняют результат. Описания зон могут иметь другие имена, не только Europe/Amsterdam: не угадывайте их смысл и не заменяйте автоматически. Сравнение двух строк даёт подсказку, но не проверяет весь календарь.

Проверьте также часовую зону отображения. Например, Google Календарь показывает событие каждому приглашённому в его местной зоне. Изменение настройки отображения отличается от переноса встречи. На двух экранах сравнивайте одну дату и одну зону.

Подтвердите нужное правило

Для нашей серии с привязкой к Амстердаму подойдёт такая формулировка: «По пятницам в 15:00 Europe/Amsterdam. 30 октября 2026 года это 10:00 America/New_York и 14:00 UTC». При расхождении попросите организатора подтвердить правило и конкретную встречу.

Если договорились о 15:00 в Амстердаме, всем трём пятницам соответствует вариант A. Если о 13:00 UTC — вариант B. Ни один из них не сохраняет 09:00 в Нью-Йорке на всех трёх датах. Исправляйте встречу средствами календаря организатора, затем проверьте все три даты. Редактирование строки .ics с повторным импортом в эту проверку не входит.

Проверьте другую привязку

Выберите ответ или откройте объяснения ниже.

Встреча должна проходить каждую пятницу в 09:00 по Нью-Йорку. Сколько будет в Амстердаме 30 октября 2026 года?

Ответы и пояснения

14:00: Верно. Нью-Йорк живёт по UTC−04:00, поэтому 09:00 соответствует 13:00 UTC. В Амстердаме UTC+01:00: получается 14:00.
15:00: Так получилось бы при разнице в шесть часов. В эту дату Амстердам уже перевёл часы, а Нью-Йорк ещё нет: разница составляет пять часов.
16:00: Переведите через UTC: 09:00 в Нью-Йорке — это 13:00 UTC, затем 14:00 в Амстердаме.