Калькулятор часовых поясов

время в пункте назначения = время источника − смещение UTC источника + смещение UTC назначения; разница смещений = смещение назначения − смещение источника; сдвиг даты = дата назначения − дата источника

date

Календарный день в исходной зоне, в виде ГГГГ-ММ-ДД. Это день там, а не день там, где читаете это вы

time

Время на часах в исходной зоне, в виде ЧЧ:ММ или ЧЧ:ММ:СС по 24-часовой шкале. Секунды можно опустить; в результате они показываются всегда

fromZone

Зона, которой принадлежит введённое время. Одна из 22 зон IANA, и каждая подписана городом, а не смещением, потому что смещение — свойство момента, а не места

toZone

Зона, в которую переводим. Те же 22 зоны, что и в списке источника

toTime

Время на часах в пункте назначения, всегда с секундами. Это главный результат

toDate

Календарная дата в пункте назначения, и она не всегда совпадает с введённой — в этом весь смысл сдвига даты

toWeekday

День недели в пункте назначения, числом от 0 (воскресенье) до 6 (суббота)

fromOffset

Насколько исходная зона смещена от UTC в разрешённый момент, в записи UTC±ЧЧ:ММ

toOffset

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

offsetDifference

Смещение назначения минус смещение источника, в часах. Отрицательное значение означает, что пункт назначения отстаёт от источника

dayShift

-1, 0 или +1: попала ли дата назначения на день раньше, на тот же день или на день позже введённого

Страница нужна всюду, где участвуют два места и часам приходится доверять: назначить звонок через океан, проверить, сядет ли самолёт в тот же день, в который вылетел, прочитать серверный журнал, написанный по UTC, или понять, почему чьё-то «воскресное утро» — это ваш вечер воскресенья. Сдвиг даты — та часть, которую люди чаще всего считают неверно, потому что это не постоянное свойство пары городов: одни и те же две зоны расходятся на 12 часов в январе и на 11 в июле. Эта страница переводит момент, который у вас уже есть; она не подсказывает, в какой зоне находится место (списки жёстко ограничены 22 зонами), и ничего не говорит о времени в пути, длительности перелёта или напоминаниях о встречах.

1. Полдень в Шанхае — в Нью-Йорке предыдущий день

   1. В январе Шанхай живёт по UTC+08:00, поэтому полдень там — это 04:00 UTC 15 января
   2. Нью-Йорк на EST, то есть UTC-05:00, поэтому 04:00 UTC читается на тамошних часах как 23:00
   3. 23:00 идёт до полуночи, а значит дата сдвигается на 14 января — на день раньше введённого, и сдвиг даты так и говорит: -1
   4. 14 января 2026 года — среда, поэтому номер дня недели равен 3
   5. Два смещения расходятся на -13 часов: 08:00 против -05:00 даёт 13 часов, и дальше на запад стоит пункт назначения

   Это исходное состояние калькулятора и тот случай, который удивляет чаще всего: сообщение, отправленное за обедом в Шанхае, доходит до Нью-Йорка в предыдущий календарный день. Считать такое в уме по правилу «Шанхай впереди на 12 или 13 часов» — как раз там и заводится ошибка: здесь ответ 13, но в июле он был бы 12, потому что Нью-Йорк переходит на летнее время, а Шанхай нет.

2. Время, которого не существует: Нью-Йорк, 8 марта 2026 года, 02:30

   1. Часы в Нью-Йорке в этот день переводят вперёд в 02:00 по местному времени, поэтому 02:00 становится 03:00, а получаса с 02:00 до 03:00 не бывает вовсе
   2. Значит, введённых 02:30 не существует. Страница читает их так, как предписывают правила IANA для пропуска: сдвигает вперёд, получая 03:30 по EDT
   3. 03:30 8 марта 2026 года — воскресенье, отсюда день недели 0
   4. Поскольку разрешённый момент уже попадает в EDT, напечатанное смещение источника равно UTC-04:00, а не UTC-05:00, которое эти 02:30 несли бы днём раньше
   5. Шанхай живёт по UTC+08:00, на двенадцать часов впереди EDT, поэтому 03:30 превращается в 15:30 того же дня

   Смещение, напечатанное рядом с введённым временем, выглядит неверным, пока не поймёшь почему: 02:30 в Нью-Йорке — это показание часов UTC-05:00 зимой, но именно эти 02:30 попадают в пропуск после перевода, поэтому момент, в который они разрешаются, принадлежит EDT и сообщает UTC-04:00. Пропуски и перекрытия страница читает так же, как предписывает база часовых поясов IANA, и никогда не отказывается принять ввод, поэтому число выдаётся всегда, и это тот случай, который стоит перечитать дважды.

3. Оба конца на летнем времени: Лондон и Лос-Анджелес 4 июля

   1. В июле Лондон живёт по BST, UTC+01:00, поэтому 09:30 там — это 08:30 UTC
   2. Лос-Анджелес живёт по PDT, UTC-07:00, поэтому 08:30 UTC — это 01:30 на тамошних часах
   3. Смещения расходятся на 8 часов — как и те 8 часов, которых ждут зимой, но это разные восьмёрки: в январе Лондон это UTC+00:00, а Лос-Анджелес UTC-08:00
   4. Оба напечатанных смещения включают своё летнее время, поэтому источник читается как UTC+01:00, а не UTC+00:00
   5. Дата не изменилась, значит сдвиг даты равен 0, а 4 июля 2026 года — суббота, день недели 6

   Если отвечать по стандартным смещениям (0 и -08:00), получится та же разница в 8 часов и то же время на часах — именно поэтому здесь ошибку легко не заметить, и она всплывает на датах по обе стороны от перехода. А вот когда обе зоны переходят в противоположные стороны на одной неделе марта, правило фиксированных смещений промахивается на целый час.

4. Новый год в Окленде — а по UTC всё ещё прошлый

   1. В январе Окленд живёт по NZDT, UTC+13:00, поэтому полночь там — это 11:00 UTC 31 декабря 2025 года
   2. Перевод в UTC поэтому пересекает сразу и границу суток, и границу года
   3. Дата назначения — 31 декабря 2025 года, а сдвиг -1 считается вычитанием номеров дней, а не сравнением строк с датами
   4. 31 декабря 2025 года — среда, день недели 3
   5. Разница смещений равна -13 часам: дальше на запад здесь стоит пункт назначения, то есть UTC

   Сдвиг даты — это не просто «запад означает вчера». Здесь -13 часов пересекают полночь; те же -13 часов между Шанхаем и Нью-Йорком тоже приводят на предыдущий день, а разница в -5 часов между Лондоном и Нью-Йорком — нет. День недели сообщается для даты назначения, поэтому и выходит среда, хотя введён был четверг.

Калькулятор покрывает 1970–2100 годы и 22 часовых пояса, а не все зоны, которые знает база IANA. Окно выбрано намеренно: до 1970 года база хранит то местное среднее время, которое там действительно держали, — Шанхай жил по UTC+08:06, а Монровия пользовалась смещением с секундами, — и такие ответы верны, но читаются как ошибка. Неоднозначные и несуществующие показания часов разрешаются так, как предписывают правила IANA (при весеннем пропуске время сдвигается вперёд, при осеннем перекрытии берётся более раннее из двух чтений), а не отклоняются; страница не предупреждает, что это произошло, поэтому даты вокруг перехода стоит сверять с показанными смещениями. Никакая зона не выводится из введённого названия места, потому что вводить его некуда: оба списка фиксированы. Страница не знает, в какой зоне находится ваше устройство, не считает длительности и время перелётов и не учитывает дополнительные секунды — в UTC их нет, и это отдельный вопрос от тех дополнительных секунд, которые в UTC добавляют.

Какова разница во времени между двумя городами?

Разница во времени между городами не является постоянным числом, и напечатанная здесь разница смещений — та, что действует на введённую дату. Две зоны могут расходиться на 13 часов в январе и на 12 в июле, потому что одна из них переходит на летнее время, а другая нет. Поэтому вопрос «какая разница между Шанхаем и Нью-Йорком» нужно задавать вместе с датой — вот почему поле даты здесь часть вопроса, а не необязательное дополнение.

Как посчитать время встречи по часовым поясам?

Поставьте встречу в той зоне, в которой её предложили, и переведите её по очереди во все остальные зоны. Для времени встречи по часовым поясам полезнее обычно не час, а сдвиг даты: звонок в 09:00 по Лондону — это 18:00 в Токио того же дня, но 04:00 в Нью-Йорке, и именно 04:00 решает, разумно ли приглашение. Поскольку страница сообщает ещё дату и день недели, видно и то, что предложение попало на чужие выходные.

Учитывается ли переход на летнее время автоматически?

Да, для обеих зон и именно на введённую дату, а не на сегодняшнюю. Летнее время — свойство не зоны, а момента: напечатанные смещения берутся из правил IANA для того мгновения, которое переводится, поэтому январь и июль между одними и теми же двумя зонами могут дать результат, отличающийся на час. Ничего о текущей дате не предполагается, а значит результат, посчитанный для следующего марта, уже включает мартовский переход.

Почему смещение UTC иногда не такое, как я ожидал?

Потому что показанное смещение принадлежит тому моменту, в который разрешился ввод, а не тем часам, которые вы набрали. В день перевода часов пропущенного часа не существует, и время, набранное внутри него, читается как момент сразу после него, — поэтому 02:30, введённые для Нью-Йорка в мартовский день перехода, сообщают UTC-04:00 (EDT), а не UTC-05:00, которое эти 02:30 несли днём раньше. Оба чтения относятся к одному и тому же моменту; смещением, действующим в нём, является только одно из них.

Какой там день, если здесь среда?

Это зависит и от часа, и от зон, поэтому страница и спрашивает оба. Пересекая линию перемены даты на восток, вы выигрываете день; переводя на запад через достаточное число часов, теряете его. Поле сдвига даты отвечает на это прямо: -1, 0 или +1, — а поле дня недели называет день в пункте назначения, поэтому видно, добралась ли та сторона уже до того дня, о котором вы спрашиваете.

• IANA Time Zone Database — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — IANA — the source for the 1970-01-01 accuracy window this page states
• Temporal documentation — Time zone handling — TC39 — describes the 'compatible' disambiguation rule this page follows