Pull to refresh
46
0
Send message

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

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

Я выше привёл ссылку на SO, которая подтверждает мои слова. Думаю, если для завершения диалога вы приведёте ссылку, которая подтверждает ваши, все читающие ветку получат полную информацию, чтобы сделать собственные выводы.

Ну представьте, что вместо митинга - отправление поезда, 10:00 каждый день. Бизнес-логика тут - "всегда 10:00". Таймзона, в которой отправляется поезд - базовая.

Это - типичная бизнес-логика для расписаний, а я именно о них и говорю.

Это не какое-то обобщение, это типовая задача с типовой реализацией, даже если это контринтуитивно. Прочитали ли вы ответ на SO, который отвечает на большинство вопросов из всего этого поста, включая этот?

Для базовой таймзоны митинг должен быть всегда в 10-00.

Потому что так работают все расписания - время никогда не сдвигается из-за DST.

Там ниже ещё одна ветка с таким же точно обсуждением будущих дат и DST.
Я там привёл хорошие ссылки на SO, повторю тут тоже: раз, два.

When scheduling future events, usually local time is preferred instead of UTC, as it is common for the offset to change. See answer, and blog post.

Да, я точно писал массовые приложения с датой-временем (успешно).

Простите, на этом я завершаю дискуссию, так как вы просто игнорируете то, что я пишу, и в то же время пытаетесь приписать мне и тут же опровергнуть то, чего я не говорил )

Плюс в карму за возможность подробно объяснить, что не так с "только UTC" :)

На практике такой календарь сделанный из расчета что все в одной таймзоне и все вместе переходят на зимнее время в 2023 не очень.

Послушайте, это не имеет значения, все или не все переходят на зимнее время. Имеет значение, что зимнее и летнее время существует, но не для UTC. Вы просто не можете хранить рекуррентное время в UTС и получать одно и то же время для всех весь год.

"Все в одной таймзоне" - это упрощённый пример, чтобы вам пояснить, в чём проблема.

В любом другом случае такая логика будет не очень.

Да во всех случаях логика хранения в UTC рекуррентного времени не очень. Ни в каком она не "очень", кроме случаев, когда вся команда находится в таймзоне без DST. Но мы же не можем реализовывать только этот случай, правда?

У людей внезапно совещание сдвинется на час. Это вызывает много непонимания и WTF у людей. Календарь не должен так работать. Он должен быть максимально предсказуемым.

Всё верно. И именно это произойдёт, если следвать вашему совету всегда и везде хранить время в UTC и конвертировать его по надобности в локальное.

Схему слежения за любой таймзоной или любым локальным временем стоит делать отдельной фичей поверх календаря в таймстемпах. Пару раз в год добавить больше или меньше не сложно. В интерфейсе одна галочка.

Позвольте мне не пояснять детали, но наслаивать рукописную логику учёта DST для всех поддерживаемых таймзон - это не то чтобы не сложно, это прямо-таки на порядок, а скорее на два сложнее, чем просто хранить дату+время (10:00) с базовой таймзоной, и конвертить из базовой таймзоны в любую другую.

Возможно, вы не верите мне, но мне пришлось довольно тщательно изучить этот вопрос, и в подтверждение вот вам ссылки на StackOverflow, с которых я начинал (а их море, так как это практически такая же вечная проблема, как инвалидация кэша):

Раз

Два

Пожалуйста, обратите внимание на пункт

When scheduling future events, usually local time is preferred instead of UTC, as it is common for the offset to change. See answer, and blog post.

В моём примере рассматривается упрощённый случай: все 10 человек в Берлине )

Но если вы будете просто добавлять 86400 к UTC дате, время всё равно сдвинется с 10:00 до 9:00 для них, когда берлинская таймзона перейдёт на зимнее время.

Если же у вас распределённая команда, то в любом случае какая-то часть команды должна быть базовой (для которой время круглогодично будет 10:00), а для всей остальной команды - будет плавать.

Но опять-таки, вам нужно для этого не только хранить время (как есть, не в UTC), но и эту базовую таймзону.

И конверсия будет проводиться для каждого конкретного времени из базовой таймзоны во вторичные.

(В комментарии я забыл проинкрементировать даты в правой колонке, для Берлина - они такие же, как для UTC).

Пользователь задает время совещания на 10-00 по Берлину. Это время завтра переводится в таймстемп и фиксируется навсегда. И задается что совещание повторяется каждые 86400 секунд.

Поясню - обратите внимание на строчку "-- Berlin переходит на зимнее время, теперь там UTC+1".

UTC не имеет DST, а Берлин - имеет. И между 28 окт, 10:00 Berlin и 29 окт, 10:00 Berlin не 86400 секунд, а на 3600 секунд меньше.

(В комментарии выше я забыл проинкрементировать даты в правой колонке, для Берлина).

Ваш пример про "переехал" совершенно нерелевантен для моего комментария. Да, если кто-то меняет сам свою таймзону - вы всё правильно говорите, остальных это не касается.

В моём примере никто никуда не переезжает и свою таймзону не меняет, а время встречи, тем не менее, сдвигается (если вы его храните в UTC и конвертируете в локальное).

Простите, но мне кажется, вы то ли не знаете, что такое DST (летнее время), то ли невнимательно прочитали мой пример.

Судя по тому, что вы упомянули 4 часа, вы не совсем поняли контекст, так как DST это никогда не 4 часа.

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

Пример с цифрами:
вы создаёте рекуррентный митинг, каждый день в 10 часов, в таймзоне UTC+1 (Berlin), 26 октября. Так как в это время действует DST, и время в Берлине UTC+2, в базе вы получите

26 октября, 8:00 UTC. Дальше сервер будет добавлять 86400  чтобы запланировать следующие митинги.

26 окт, 8:00 UTC => 26 окт, 10:00 Berlin
27 окт, 8:00 UTC => 26 окт, 10:00 Berlin
28 окт, 8:00 UTC => 26 окт, 10:00 Berlin
-- Berlin переходит на зимнее время, теперь там UTC+1
29 окт, 8:00 UTC => 26 окт, 9:00 Berlin

Что это, как не изменение времени встречи? :)

Если участники встречи находятся в разных таймзонах с разным DST, вам необходимо определить, для какой из таймзон митинг будет всегда 10:00, а для кого - меняться.

Там, на самом деле, есть и ещё нюансы - например, DST может меняться даже для одной таймзоны (решением правительств).

По этой циферке ни один разработчик или аналитик не сделает неверного предположения или неверных выводов. Там просто негде ошибаться.

Например, надо вам создавать рекуррентные задачи - каждый день в 10-00 у вас митинг.
Вы храните дату как UTC timestamp.
Вы создаёте первую задачу, когда у вас действует DST, и дальше сервер за вас создаёт задачи, добавляя ровно сутки к дате предыдущей задачи.

Когда DST у вас перестаёт действовать, вы видите, что ваш митинг теперь не в 10-00, а в 9-00.

При этом для вашего колеги в таймзоне, для которой DST не применяется, митинг, конечно, будет по его старому локальному времени.

Для таких случаев лучше хранить дату и время "как есть", без конверсий в UTC, но хранить также и "базовую" таймзону (того, для кого митинг всегда будет в 10-00) - чтобы из неё конвертировать в зоны других юзеров с учётом DST.

Да, но в контексте статьи и обсуждения именно хранение в UTC/хранение как есть - это ключевое отличие типов.

В MySQL тип timestamp сразу имеет поведение как timestamptz в PostgreSQL

В MySQL есть DATETIME, который соответствует timestamp из PostgreSQL.

Надо заметить, что 60 делится на 12, 15, 20 и 30 практически с той же лёгкостью, как и на 2, 3, 4, 5, 6 и 10.

Однажды мы вместе обедали, и он рассказал мне, что прежде, чем приехать
в Лос-Аламос, он работал в Англии.
— Какой работой вы там занимались? — спросил я.
— Я занимался металлизацией пластмасс. Я был одним из молодых
сотрудников в лаборатории.
— Как шло дело?
— Довольно хорошо, но у нас были кое-какие трудности.
— Вот как?
— Когда мы только начали разрабатывать процесс, в Нью-Йорке объявилась
компания…
— Какая компания в Нью-Йорке?
— Она называлась корпорация «Метапласт». Они продвинулись дальше, чем
мы.
— Откуда вы знаете?
— Они все время рекламировали себя в «Современных пластмассах», помещая
на всю страницу объявления с картинками тех вещей, которые они могли
покрывать металлом, и мы поняли, что они ушли далеко вперед.
— Вы видели какое-нибудь их изделие?
— Нет, но по этой рекламе можно было сказать, что они нас опередили.
Наш процесс был довольно хорош, но не было смысла даже пытаться
соревноваться с американским процессом вроде того, какой был у них.
— Сколько химиков работало в вашей лаборатории?
— У нас было шесть химиков.
— Как вы думаете, сколько химиков было у корпорации «Метапласт»?
— О, у них, должно быть, был настоящий химический отдел!
— Не могли бы вы описать мне, как, на ваш взгляд, мог бы выглядеть
главный химик-исследователь корпорации «Метапласт» и как могла работать его
лаборатория.
— Насколько представляю себе, у них было 25 или 50 химиков, а у
главного химика-исследователя свой собственный кабинет, специальный, со
стеклом. Знаете, как показывают в фильмах. Молодые ребята все время заходят
с исследовательскими проектами, над которыми они работают, получают у него
совет и бегут работать дальше, люди постоянно снуют туда-сюда. При их 25 или
50 химиках, как, черт возьми, можно было с ними конкурировать?
— Вам будет интересно и забавно узнать, что сейчас вы беседуете с
главным химиком-исследователем корпорации «Метапласт», чей штат состоял из
одного мойщика бутылок!

(С)
С удивлением узнал, что зарука была в фурмановском оригинале.
Токомак

ТОроидальная КАмера с МАгнитными Катушками

Information

Rating
Does not participate
Location
Харьков, Харьковская обл., Украина
Registered
Activity