Комментарии 56
Пример с кофе имеет и обратную сторону. Я тоже пил кофе в области с временем на час больше моего, потом вернулся и опять попил кофе, в итоге в банковском приложении получилось, что второй кофе я попил раньше первого.
Если бы там обозначался часовой пояс, то, может, и было бы понятнее, но визуального мусора прибавилось бы.
Ещё бывает, что в поезде ставишь будильник и не знаешь, успеет ли телефон перейти на другой часовой пояс к тому моменту. А по проводнику просыпаться хуже, потому что в туалет будут очереди.
Ещё бывает, что в поезде ставишь будильник и не знаешь, успеет ли телефон перейти на другой часовой пояс к тому моменту.
Авиарежим?
Ещё бывает, что в поезде ставишь будильник и не знаешь, успеет ли телефон перейти на другой часовой пояс к тому моменту.
Вроде в календаре события к UTC привязаны, можно для таких случаев там напоминалку ставить.
Ещё бывает, что в поезде ставишь будильник и не знаешь, успеет ли телефон перейти на другой часовой пояс к тому моменту.
Лайфхак ))) ставишь два будильника, как только проснулся - второй отключаешь (не благодарите)...
Буквально на днях завирусилась пара постов на тему WTF с датами в js, где как раз возникал вопрос, какого фига это до сих пор в таком виде существует
Сами посты
А что не нравится Кристине? Оба конструктора, из числа и строки, работают вполне ожидаемо. Ну, может быть, стоило бы сделать конструктор из строки построже, чтобы год требовал хотя бы двух разрядов, т.е. ведущего нуля, а голый год в дате — всех четырёх.
Настоящая проблема в том, что в ES до сих пор нет режима запрета неявных типопреобразований (и можно нечаянно передать '0' вместо 0).
Как паллиатив, я бы сделал фабрику дат с кучей статических методов .fromWhat().
как раз возникал вопрос, какого фига это до сих пор в таком виде существует
Потому что программисты занимались более важными вещами - например, совместимостью с двумя китайскими и пятью исламскими календарями.
Можно было бы расширить Zoned Date Time. И сразу прилепить GPS координаты оставив еще поле под расширение для полетов за кофе на Марс.
Многие считают, что работая с UTC или передавая данные в формате ISO, они обеспечивают безопасность, однако это не так, информация всё равно теряется.
Не очень понял аргументацию. Как она может теряться, если дата-время в UTC гарантированно обозначают ровно одну точку во времени? Про ISO-формат согласен, но в чем проблема хранить в UTC, а потом преобразовывать в таймзону клиента при отображении?
Судя по всему, проблема в том, что Date - страшно неправильное название. Должно быть Instant. Стандартная ошибка всех старых языков.
И тип использовали для того, для чего не надо бы (ввиду отсутствия альтернативы). Дата, которая выбирается в каком-нибудь виджете календаря или пишется на документе - это на самом деле интервал между двумя точками во времени. И когда ты вместо этого интервала получаешь Date (с установленными в 0 часом/минутой) - то ты, действительно, теряешь информацию - понять, какие именно точки были началом и концами этого интервала, нельзя.
Дата, которая выбирается в каком-нибудь виджете календаря или пишется на документе - это на самом деле интервал между двумя точками во времени.
This is ground control to major Tom… )))))
Крайне сомневаюсь, что такая концепция даты зашла бы массовому программеру.
Крайне сомневаюсь, что такая концепция даты зашла бы массовому программеру.
Тем не менее, 'дата' именно это и означает, если подумать и если работаешь над/в системе, размазанной по таймзонам. И потом человек, сидящий в Москве, хочет посмотреть список событий за 'вчера', произошедших в Владивостоке. ("За чье 'вчера'? И когда оно началось?")
А так да, не очень заходит. Скажем в xml/xsd это сформулировали практически правильно. (потому что его придумывали как средство переноса данных между системами):
[Definition:] date represents top-open intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day, up to but not including the beginning moment of the next day). For non-timezoned values, the top-open intervals disjointly cover the non-timezoned timeline, one per day. For timezoned values, the intervals begin at every minute and therefore overlap.
Но когда всякие парсеры XML эти даты читают - ооочень редко когда оно превращается именно в интервал.
Я думаю, что для большинства дата это Instant, округлённый до дней. А если рассматривать его как интервал, придётся опять от округлённости переходить к ненужной точности.
Например, в календаре можно установить для всех евентов, назначенных на даты без времени, начало рабочего дня, скажем, в 8-00, а с интервалами придётся указывать 8-00 сразу. А если к этому времени человек начнёт работать с 9-00?
Например, в календаре можно установить для всех евентов, назначенных на даты без времени, начало рабочего дня, скажем, в 8-00, а с интервалами придётся указывать 8-00 сразу. А если к этому времени человек начнёт работать с 9-00?
Не понял примера. событие с датой, но без времени - требует указания часового пояса, чтобы определять, когда эта дата начинается и кончается. Часовый пояс косвенным образом определяет интервал начала и конца даты.
Потому что событие назначенное на "2024-08-26" - может произойти, скажем, в 11 часов вечера по московскому времени. Но во Владивостоке оно же - это уже 27-ое число.
Если у меня билет на 1 сентября, и из-за часовых поясов возможен попадос, я укажу ТОЧНОЕ ВРЕМЯ.
А если мне надо оплатить Интернет 1 сентября и я создаю напоминалку на 1 сентября (или 1-е число каждого месяца), мне глубоко фиолетовы эти тонкости. И если в интерфейсе приложения всплывут корни (дата это промежуток между двумя точными точками), я его выкину. А если не всплывут, то программист вынужден будет писать свою дату (может быть, на базе промежутковой).
А если мне надо оплатить Интернет 1 сентября и я создаю напоминалку на 1 сентября (или 1-е число каждого месяца), мне глубоко фиолетовы эти тонкости.
Потом расшариваешь кому-то календарь, это кто-то напоминалку видит, находясь в другом часовом поясе и в результате промахивается с датой.
интерфейсе приложения всплывут корни
Всплывут. Если не интерфейсе, так при общении. Потому что "созваниваемся 1-го числа у меня или у тебя?"
Да и разные - "У нашего офиса <там-то> рабочее время по нашему времени какое?". Тот самый интервал. Оно очень быстро всплывает. Вот как хранить - это можно по разному справляться.
Или даже: "Паспорт выдан <дата>", что в базе записали неудачно в виде Instant на начало дня московского времени. Человек идет в отделение банка опять же во Владивостоке и получает "а у вас срок действия паспорта вчера вышел". (Интересно, кстати, как юристам положено этот вопрос решать при удаленном обслуживании. Всякое совершеннолетие итд итп).
Потом расшариваешь кому-то календарь, это кто-то напоминалку видит, находясь в другом часовом поясе и в результате промахивается с датой.
И что случится? Интернет будет оплачен не в восемь утра, а в четыре часа дня? Или даже на следующий день? Вот ведь беда-то какая!
Ну а если провайдер — мелочная скотина без грейс-периода и с посекундной тарификацией (у меня, кстати, как раз именно такой), я ставлю в настройке евента «Показывать reminder за 3 дня». То есть, опять же, я буду оперировать теми единицами (днями), в которых мне удобно вести подсчёты. Не надо требовать от меня задумываться о часах, когда речь идёт о днях.
Если речь пойдёт о таком событии, для которого важна точность (билет на балет), я буду думать в часах, минутах и секундах.
Что касается языков, платформ и фреймворков, то они отражают ожидания и подходы. Именно поэтому (по моему скромному мнению) мы имеем то, что имеем.
бизнес-процессы могут быть привязаны к местному времени. Сохраняя дату в UTC, мы теряем информацию о местном времени. Другими словами из 13:00 UTC мы не можем восстановить 16:00 MSK
Можем, для этого есть таймзона которую можно передать отдельно.
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)
Лучше всего передавать аналог DateTimeOffset как в C#, при помощи сторонних либ.
Многим вообще только УТС и хватает, их не интересует время клиента, нужен только точный момент времени. Учитывая что такого не может быть, где гарантия что на клиенте время верно указано, это если докапываться до миллисекунд. Проблема не новая, и раз все еще так работает значит большого кипеша нет.
Новое апи круто, посмотрим.
Можем, для этого есть таймзона которую можно передать отдельно.
о том и речь. Информацию о зоне MSK мы уже потеряли, сохранив дату в UTC
Многим вообще только УТС и хватает, их не интересует время клиент
так понятно, что бизнес-требования у всех разные. Поэтому и существует два подхода. Об этом даже на хабре с пяток статей.
Согласен с коллегами выше, хранить и пользоваться лучше временной меткой UTC. Только показать в нужном формате.
Разницы поудобнее наверное юзать.
Я просто оставлю это здесь: https://mol.hyoo.ru/#!section=docs/=giikl8_xe40dd
4кб и вы получаете простой и универсальный апи уже сейчас с поддержкой не только времени, но и интервалов.
Самый главный вопрос: стандартными способами подключается? Я не хочу ради одной фичи тащить в проект ещё одну систему управления зависимостями.
Доку не читай @ вопросы задавай.
Стандартными, но довольно оригинально:
import('https://cdn.jsdelivr.net/npm/mol_time_all@1.1.1096/web.mjs')
.then(({default:Module}) => {
debugger
console.log(new Module.$mol_time_moment().toString());
});Default-экспорт es6-модуля для браузера представляет собой глобальный объект Window:
Наверное, в этом есть какой-то смысл, но явно неявный.
Вам ли не знать про Inversion of Control? Это дефолтный контекст окружения.
В моей секте этот тип IoC не считается кошерным.
Ваш подход к построению браузерного приложения мне кажется эгоцентричным до солиптичности. Это неплохо в одних некоторых случаях (когда вы самый главный в песочнице), но может сильно мешать в других некоторых случаях (когда каждый считает себя самым главным в песочнице).
Я как-то в Magento-магазине совмещал больше пяти jQuery-библиотек разных версий, которые тянулись различными Magento-плагинами, и пришёл в восторг, что это всё работает (я тогда только-только из Java вышел). А в вашем подходе я вижу регресс в этом вопросе:
import('https://cdn.jsdelivr.net/npm/mol_time_all@1.1.1096/web.mjs')
.then(({default: Module96}) => {
import('https://cdn.jsdelivr.net/npm/mol_time_all@1.1.1095/web.mjs')
.then(({default: Module95}) => {
const polluted = (Module95 === Module96);
debugger
});
});Лично я предпочитаю держать свой global object Window в чистоте и иметь возможность пользоваться разными версиями одной и той же библиотеки. Так-то мне это обычно не надо, но иметь возможность лучше, чем её не иметь.
Вы на стиле!! :))) Что "тут" и "тут"? Вы даёте ссылки на свои статьи, которые хоть каким-то боком относятся к дискутируемому вопросу и сваливаете в закат. Вы так рейтинг своего hyoo.ru в поисковиках поднимаете?
Вот так делается нормальное версионирование на нормальных платформах
Код:
import('https://cdn.jsdelivr.net/npm/svelte@4.2.19/+esm')
.then((Svelte4) => {
import('https://cdn.jsdelivr.net/npm/svelte@5.0.0-next.239/+esm')
.then((Svelte5) => {
const polluted = (Svelte4 === Svelte5);
debugger
});
});Нажмите F12, скопируйте код в консоль браузера, запустИте, а затем походИте в отладчике по переменным и скоупам - посмотрИте, как выглядит в runtime код, спроектированный для работы с кодом других разрабов.
ОценИте кол-во элементов в импорте для Svelte (13 штук) и ваших добавлений в window с префиксом $mol_ (24 штуки). А ведь я подключил лишь одну вашу библиотеку по работе с датами. Представьте теперь, что будет в window, когда я подключу другие ваши библиотеки, свои модули, модули других разработчиков (подскажу - как все файлы на компьютере, если их собрать в одном каталоге).
В общем, ваш $mol - это аналог parser Студии Лебедева. Хороший инструмент для решения некоторого подмножества задач. Главное - не выходить за границы его применимости (студии).
Вместо того, чтобы писать тут столько глупостей, лучше бы сходили по ссылкам и почитали, что более опытные люди пишут. Там не много, глаза не отсохнут.
Ну и для справки: Svelte - не полноценный аналог $mol_view - одного из сотен модулей в $mol.
Мне тут чат-гопота разложила по понятиям:
Крауд-маркетинг — это метод продвижения, при котором размещаются комментарии, сообщения или ответы на тематических форумах, в социальных сетях, блогах и других онлайн-платформах с целью привлечения внимания к продвигаемому сайту, продукту или услуге. Часто такие сообщения содержат ссылки на основной сайт, который нужно продвигать в поисковых системах.
Главная идея заключается в том, чтобы создавать полезный контент и взаимодействовать с целевой аудиторией в рамках обсуждений, тем самым органично вставляя ссылки. Однако, если это делается без учета контекста и выглядит как спам, такие действия могут принести негативный эффект и повредить репутации компании или сайта.
Перефразируя известный афоризм про деньги - "неважно, о чём начинает говорить Карловский, Карловский всегда и всё сводит к hyoo".
И в оригинале, и в переводе что-то не так со сниппетом про сравнение времени ( one/two) - выглядит так, что либо должна быть разная таймзона в разных строчках, либо как-то ещё указано, что в two время наступило второй раз.
А это точно хорошее решение привязывать таймзону к строковым литералам "Europe/Madrid" или "Asia/Tokio"? Понятно, что для удобства разработчика сделано, но что делать если вдруг гео-политическая реальность вмешается в действительность (не дай бог, конечно)?
Это единственное хорошее решение. Из даты с частью Z+3:00 вы не можете восстановить местное время события, потому что DST, да и просто зоны иногда меняются властями. Так что да, таймзону придётся хранить вечно, tzdata обязательна и будет только расти и пухнуть
Вот именно. И dst, и сами таймзоны меняются периодически. Поэтому для полного понимания нужно после наименования зоны указывать ещё и текущий таймстамп, чтобы обозначить время применения смещения. И вдобавок иметь под рукой справочник: таак, вот в 12 ночи такого-то числа 2013 года отменили dst; потом тогда-то вернули.
А для указания времени применения тоже ведь нужно часовой пояс указать. Так, погодите-ка...
Да, потому что это не просто строковые литералы, а скорее регионы. Например в UTC +3:00 может быть несколько регионов и проблема в том, что в одном из них может быть перевод на летнее время, а в другом нет. Вообще автор не упомянул о летнем времени, а это очень важный момент.
Откровенно говоря, zoned time не нужен вообще и UTC даты более чем достаточно. Вы мля приводите примеры с платежами где клиентское время в браузере вообще не может участвовать. И прочую дичь. Улучшения безусловно нужны, но примеры - высосаны из пальца и к жизни не имеют отношения.
мы будем знать только количество миллисекунд, прошедших с эпохи UNIX, и смещение
Если коротко, то "нет", если полнее то "вот вообще нет".
tl;dr: читайте спеку и описание сами.
статья как будто мусорная и ничего не объясняет. она просто обрывается на том месте где нужно объяснять
Удобно для описания и работы с датами. Но я так понял, в БД мы всё равно будем складывать "timestamp"? 🤔
Неиувидел, как записывается время в день перехода на летнее время? В этот день 2 часа ночи случается два раза в течение часа, до перевода часов и после, как отличить эти два момента?
Все также в УТС, там нет перевода. Перевод будет видно только в при конвертации в тот часовой пояс где этот перевод есть. И то конвертацию просто так не сделать, надо сходить в АПИ для запроса времени перевода и затем рассчитать локальное. Просто добавить оффсет как это делают в большинстве случаев недостаточно.
Самое простое - храни в УТС, все остальное можно рассчитать. Если можешь хранить DateTimeOffset (C#), то это удобнее.
А есть ли проблема? Сто лет храним данные о дате/времени на сервере в формате unixtime, который спокойно преобразуется в utc и далее форматируется в нужный вид для клиента. Если же так важен контекст времени, то можно хранить зону в соседней колонке таблицы бд. Но мне это никогда не было нужно. Хранение зон, языка браузера и прочей инфы - это дополнительная инфа, а база - unixtime/utc.
Я правильно понимаю, что все проблемы из-за DST? Не то, чтобы я предлагаю отменить переход на летнее время... Хотя...
Даты в Javascript наконец-то пофиксят