В ваших комментариях под вопросом вы сказали:
Текущее решение, которое у меня есть, заключается в том, что я сохраняю рабочее время пользователя A в качестве времени начала и окончания для каждого дня недели. Я также храню пользователей TimeZone. В настоящее время API вернет Рабочее время в виде JSON-данных с рабочими TimeZone. Затем я отображаю эти данные для пользователя B и выполняю настройку со смещением TimeZone пользователя B, используя клиентскую JS. Когда пользователь B решает забронировать, запрос обратно к API выполняется с использованием настройки TimeZone пользователя A, а затем это значение даты и времени преобразуется и сохраняется в формате UTC.
Это в основном хорошо, за исключением случаев, когда вы говорите, что выполняете настройку, используя смещение часового пояса пользователя B.
Проблема в том, что многие часовые пояса проходят различные смещения в зависимости от того, о какой дате и времени вы говорите. Например, если в JS на стороне клиента вы делаете что-то вроде new Date().getTimezoneOffset(), вы получаете смещение current пользователя. Это не обязательно то же самое смещение, которое должно применяться к рассматриваемой дате. Подробнее об этом под заголовком «Часовой пояс! = Смещение» в теге часового пояса вики .
Кроме того, вы продолжаете говорить, что запрос к API выполняется в часовом поясе пользователя A (что нормально), но затем вы конвертируете и сохраняете время как UTC. Будьте осторожны - вам нужно сохранить запланированное время встречи. Хорошо знать, какое может быть время UTC для конкретного события, но на самом деле это тоже может измениться.
В качестве примера рассмотрим последние изменения часового пояса, произошедшие в Марокко . Они планировали завершить переход на летнее время 28 октября 2018 года, переключив часы с UTC + 1 на UTC + 0. Тем не менее, 26 октября 2018 года, предупредив всего два дня, правительство объявило, что они останутся на UTC + 1 навсегда и отменит летнее время. Подобные краткосрочные изменения очень проблематичны, и это уже случалось во всем мире много раз. Я написал сообщение в блоге о них пару лет назад, которое все еще широко применяется сегодня.
Итак, если пользователь A находился в Марокко, и вы сохранили встречу в течение некоторого времени после изменения в UTC, то, так как изменения не произошло, их назначение теперь будет отображаться на час в местном календаре.
В таких случаях, если вы сохранили предполагаемое местное время события, вы также можете иметь процесс для пересчета времени UTC на основе того, какие данные о часовом поясе вы установили. Изменения в короткие сроки являются очень сложными, но если бы было уведомление за несколько месяцев, то у вас было бы время, чтобы применить обновления и скорректировать время событий программным путем. Если бы вы хранили только время UTC, у вас не было бы этой способности.
Еще один способ подумать об этом заключается в том, что, хотя UTC всегда продолжает двигаться вперед последовательно (за исключением некоторых случаев, примерно в високосные секунды), люди не думают в таких терминах. Если я скажу, что хочу встретиться с вами в 10 часов утра в каком-то месте, собрание будет соответствовать местному времени этого места - независимо от того, какие изменения происходят между временем в этом месте и временем UTC.
И наоборот, планирование собрания на основе UTC означает, что он слепо верит в то, что не произойдет никаких изменений, кроме того, что прогнозируется в настоящее время. Поскольку мы не можем заглянуть в будущее, нам не следует делать такие предположения.
(И снова, если вам нужна помощь с кодом, пожалуйста, покажите, какой код вы пытались задать в своем вопросе. Обычно в .NET для этого используется класс TimeZoneInfo. Вот краткий обзор как это использовать .)