чатик говорит, что "на запуск двигателя уходит очень мало топлива - примерно столько же, сколько двигатель расходует за 5-10 секунд работы на холостом ходу"
tl;dr И так, из всего выше перечисленного и выше приведенного за ранее делаем вывод, что для самых НОВИЧКОВ это просто - ПЕРЕДАЧИ. Программный код - это просто, для этого мы как обычно открываем теги JavaScript! Чтобы это значение вывести на экран. Спасибо за внимание, с вами был.
A p element's end tag can be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, dialog, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, search, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element.
Ой, простите - мне показалось, что это ответ мне, и в таком контексте я прочитал комментарий, как "всё равно храни в UTC, просто добавь смещение" - потому что мне уже несколько раз отвечали в таком духе.
Вы, безусловно, можете обвесить всё дополнительной логикой по подсчёту смещений для каждой конкретной даты с учётом DST. Просто это сложнее и ненадёжно, и поэтому так не делают.
Я выше привёл ссылку на SO, которая подтверждает мои слова. Думаю, если для завершения диалога вы приведёте ссылку, которая подтверждает ваши, все читающие ветку получат полную информацию, чтобы сделать собственные выводы.
Ну представьте, что вместо митинга - отправление поезда, 10:00 каждый день. Бизнес-логика тут - "всегда 10:00". Таймзона, в которой отправляется поезд - базовая.
Это - типичная бизнес-логика для расписаний, а я именно о них и говорю.
Это не какое-то обобщение, это типовая задача с типовой реализацией, даже если это контринтуитивно. Прочитали ли вы ответ на SO, который отвечает на большинство вопросов из всего этого поста, включая этот?
Да, я точно писал массовые приложения с датой-временем (успешно).
Простите, на этом я завершаю дискуссию, так как вы просто игнорируете то, что я пишу, и в то же время пытаетесь приписать мне и тут же опровергнуть то, чего я не говорил )
Плюс в карму за возможность подробно объяснить, что не так с "только UTC" :)
На практике такой календарь сделанный из расчета что все в одной таймзоне и все вместе переходят на зимнее время в 2023 не очень.
Послушайте, это не имеет значения, все или не все переходят на зимнее время. Имеет значение, что зимнее и летнее время существует, но не для UTC. Вы просто не можете хранить рекуррентное время в UTС и получать одно и то же время для всех весь год.
"Все в одной таймзоне" - это упрощённый пример, чтобы вам пояснить, в чём проблема.
В любом другом случае такая логика будет не очень.
Да во всех случаях логика хранения в UTC рекуррентного времени не очень. Ни в каком она не "очень", кроме случаев, когда вся команда находится в таймзоне без DST. Но мы же не можем реализовывать только этот случай, правда?
У людей внезапно совещание сдвинется на час. Это вызывает много непонимания и WTF у людей. Календарь не должен так работать. Он должен быть максимально предсказуемым.
Всё верно. И именно это произойдёт, если следвать вашему совету всегда и везде хранить время в UTC и конвертировать его по надобности в локальное.
Схему слежения за любой таймзоной или любым локальным временем стоит делать отдельной фичей поверх календаря в таймстемпах. Пару раз в год добавить больше или меньше не сложно. В интерфейсе одна галочка.
Позвольте мне не пояснять детали, но наслаивать рукописную логику учёта DST для всех поддерживаемых таймзон - это не то чтобы не сложно, это прямо-таки на порядок, а скорее на два сложнее, чем просто хранить дату+время (10:00) с базовой таймзоной, и конвертить из базовой таймзоны в любую другую.
Возможно, вы не верите мне, но мне пришлось довольно тщательно изучить этот вопрос, и в подтверждение вот вам ссылки на StackOverflow, с которых я начинал (а их море, так как это практически такая же вечная проблема, как инвалидация кэша):
В моём примере рассматривается упрощённый случай: все 10 человек в Берлине )
Но если вы будете просто добавлять 86400 к UTC дате, время всё равно сдвинется с 10:00 до 9:00 для них, когда берлинская таймзона перейдёт на зимнее время.
Если же у вас распределённая команда, то в любом случае какая-то часть команды должна быть базовой (для которой время круглогодично будет 10:00), а для всей остальной команды - будет плавать.
Но опять-таки, вам нужно для этого не только хранить время (как есть, не в UTC), но и эту базовую таймзону.
И конверсия будет проводиться для каждого конкретного времени из базовой таймзоны во вторичные.
Пользователь задает время совещания на 10-00 по Берлину. Это время завтра переводится в таймстемп и фиксируется навсегда. И задается что совещание повторяется каждые 86400 секунд.
Поясню - обратите внимание на строчку "-- Berlin переходит на зимнее время, теперь там UTC+1".
UTC не имеет DST, а Берлин - имеет. И между 28 окт, 10:00 Berlin и 29 окт, 10:00 Berlin не 86400 секунд, а на 3600 секунд меньше.
(В комментарии выше я забыл проинкрементировать даты в правой колонке, для Берлина).
чатик говорит, что "на запуск двигателя уходит очень мало топлива - примерно столько же, сколько двигатель расходует за 5-10 секунд работы на холостом ходу"
Если переулок прямо сейчас свободен, то зачем ехать в загруженный? Какая разница, что будет потом, вы-то его уже проедете, пока он свободен?
tl;dr
И так, из всего выше перечисленного и выше приведенного за ранее делаем вывод, что для самых НОВИЧКОВ это просто - ПЕРЕДАЧИ. Программный код - это просто, для этого мы как обычно открываем теги JavaScript!
Чтобы это значение вывести на экран.
Спасибо за внимание, с вами был.
Просто выделите весь текст.
Claude может произвольно игнорировать инструкции из CLAUDE.md, если он слишком большой. 582 - это большой.
https://code.claude.com/docs/en/memory
Почему "Пёс в сапогах" в 11-00 вс, первая программа, не подчёркнут? Кто пасёт бедных овечек?
А Клубкино путешествие в 16-10?
Да и "ручка" явно paint.
Пустышка!
</p> можно опускать по стандарту:
Вангеры!
тся :)
Для справки:
Ой, простите - мне показалось, что это ответ мне, и в таком контексте я прочитал комментарий, как "всё равно храни в UTC, просто добавь смещение" - потому что мне уже несколько раз отвечали в таком духе.
Вы, безусловно, можете обвесить всё дополнительной логикой по подсчёту смещений для каждой конкретной даты с учётом DST. Просто это сложнее и ненадёжно, и поэтому так не делают.
Я выше привёл ссылку на SO, которая подтверждает мои слова. Думаю, если для завершения диалога вы приведёте ссылку, которая подтверждает ваши, все читающие ветку получат полную информацию, чтобы сделать собственные выводы.
Ну представьте, что вместо митинга - отправление поезда, 10:00 каждый день. Бизнес-логика тут - "всегда 10:00". Таймзона, в которой отправляется поезд - базовая.
Это - типичная бизнес-логика для расписаний, а я именно о них и говорю.
Это не какое-то обобщение, это типовая задача с типовой реализацией, даже если это контринтуитивно. Прочитали ли вы ответ на SO, который отвечает на большинство вопросов из всего этого поста, включая этот?
Для базовой таймзоны митинг должен быть всегда в 10-00.
Потому что так работают все расписания - время никогда не сдвигается из-за DST.
Там ниже ещё одна ветка с таким же точно обсуждением будущих дат и DST.
Я там привёл хорошие ссылки на SO, повторю тут тоже: раз, два.
Да, я точно писал массовые приложения с датой-временем (успешно).
Простите, на этом я завершаю дискуссию, так как вы просто игнорируете то, что я пишу, и в то же время пытаетесь приписать мне и тут же опровергнуть то, чего я не говорил )
Плюс в карму за возможность подробно объяснить, что не так с "только UTC" :)
Послушайте, это не имеет значения, все или не все переходят на зимнее время. Имеет значение, что зимнее и летнее время существует, но не для UTC. Вы просто не можете хранить рекуррентное время в UTС и получать одно и то же время для всех весь год.
"Все в одной таймзоне" - это упрощённый пример, чтобы вам пояснить, в чём проблема.
Да во всех случаях логика хранения в UTC рекуррентного времени не очень. Ни в каком она не "очень", кроме случаев, когда вся команда находится в таймзоне без DST. Но мы же не можем реализовывать только этот случай, правда?
Всё верно. И именно это произойдёт, если следвать вашему совету всегда и везде хранить время в UTC и конвертировать его по надобности в локальное.
Позвольте мне не пояснять детали, но наслаивать рукописную логику учёта DST для всех поддерживаемых таймзон - это не то чтобы не сложно, это прямо-таки на порядок, а скорее на два сложнее, чем просто хранить дату+время (10:00) с базовой таймзоной, и конвертить из базовой таймзоны в любую другую.
Возможно, вы не верите мне, но мне пришлось довольно тщательно изучить этот вопрос, и в подтверждение вот вам ссылки на StackOverflow, с которых я начинал (а их море, так как это практически такая же вечная проблема, как инвалидация кэша):
Раз
Два
Пожалуйста, обратите внимание на пункт
В моём примере рассматривается упрощённый случай: все 10 человек в Берлине )
Но если вы будете просто добавлять 86400 к UTC дате, время всё равно сдвинется с 10:00 до 9:00 для них, когда берлинская таймзона перейдёт на зимнее время.
Если же у вас распределённая команда, то в любом случае какая-то часть команды должна быть базовой (для которой время круглогодично будет 10:00), а для всей остальной команды - будет плавать.
Но опять-таки, вам нужно для этого не только хранить время (как есть, не в UTC), но и эту базовую таймзону.
И конверсия будет проводиться для каждого конкретного времени из базовой таймзоны во вторичные.
(В комментарии я забыл проинкрементировать даты в правой колонке, для Берлина - они такие же, как для UTC).
Поясню - обратите внимание на строчку "-- Berlin переходит на зимнее время, теперь там UTC+1".
UTC не имеет DST, а Берлин - имеет. И между 28 окт, 10:00 Berlin и 29 окт, 10:00 Berlin не 86400 секунд, а на 3600 секунд меньше.
(В комментарии выше я забыл проинкрементировать даты в правой колонке, для Берлина).