Обновить

Комментарии 17

Как-будто дипломную работу прочитал. К середине уже булькать начал. Но в целом познавательно.

Всё никак не удавалось понять, чем Временный лучше Даты. Но с этой статьёй смысл до меня дошёл. Наконец-то ещё один неизменяемый кирпичик в экосистему JS!

ИИ-комменты теперь и на Хабре?

Живём во время нейро комментаторов и ботов. Шош поделать )

Мне кажется это перевод супергероики в стиле Володарского. Временный против Даты, Желчный против радиоактивных людей

Ночью я мыслю как не очень умная нейросеть, днём - вообще стараюсь не думать.

Бред какой-то. Ваша проблема в том, что вы не хотите менять значение, но меняете? Ну не хотите - не меняйте. Или над вами обязательно дядя с палкой стоять должен?

Новый API выглядит более продуманным, да и похож на аналогичные в других языках. А Date да, к нему так-то давно вопросов накопилось. Неспроста же появились библиотеки moment и date-fns. Возможно теперь от них можно будет избавиться (но это не точно).

Это всё хорошо, конечно, но уж больно избыточный API, например, как получить utcNow

Стало: Temporal.Now.zonedDateTimeISO('UTC')

Было: new Date()

У вас какая-то квота на кол-во символов?

Квота на время набора + чем больше визуального шума, тем сложнее воспринимать

Вы, видимо, не очень много с датами работали. Как-то странно вы судите об избыточности API используя пример, где Temporal не нужен совсем. React/Vue/Angular тоже какие-то избыточные и непонятно зачем нужны, ведь чтобы отрисовать <div>Hello World!</div> в React надо ~10 строчек кода + килобайты зависимостей + бандлить это всё, хотя можно просто в index.html написать <div>Hello World!</div>

С простого: как получить текущее время в другой таймзоне?
Стало: Temporal.Now.zonedDateTimeISO('Asia/Tokyo')
Было: const dateInTokyo = new Date(
new Date().toLocaleString("en-US", { timeZone: "Asia/Tokyo" })
);

А как получить начало текущего дня в другой таймзоне? А потом перевести её на начало дня в третьей таймзоне? Одна-две строчки в Temporal или несколько часов отладки с Date и оно всё равно криво будет работать

Скажем так, работал много, но, к счастью, на бэкенде, и все эти часовые пояса и DST мне до свечки. UTC везде - вот мой выбор

Никаких возражений, что операции с таймзонами нужны, нет. И Date крайне убог. Но со своей колокольни вижу очень многословный API для простейшего и самого частого действия

используя пример, где Temporal не нужен совсем

Это вы скажите комитету, который уже анонсировал Date как legacy, когда Temporal устаканится

Java в названии надо как-то оправдывать

Было бы интереснее, если бы DateTime и прочее почерпнули из luxon. А то получается, что хотят, как с Intl, под одну гребёнку все завернуть, только в отличии от оного даты используются куда чаще и присутствует некая избыточность синтаксиса.

Я по старинной привычке просто храню и таскаю даты как строки в ISO формате и строго в UTC зоне. Можно сравнивать, они иммутабельны, их можно засунуть в любую библиотеку, JSON и посылать по сети. Использую Date/moment/luxon/dayjs только для операций над датами (вроде вашей add/subtract) или форматирования (Intl), да и то для таких операций всегда лежат заготовленные функции обертки, так что инлайново в коде объекты почти не встретить. Если надоело добавлять дни с помощью moment, можно в обертке заменить на dayjs, прогнать тесты и радоваться.
С TypeScript строки еще и брендированны, так что что попало без валидации не назначить. Требуется boilerplate код, чтобы все нюансы покрыть, но последний раз обновлял код года 3 назад, когда мигрировали с moment на dayjs.
Когда Temporal доберется до повсеместного распространения, вот тогда я просто окончательно избавлюсь от 3rd party библиотек, но от строковых ISO дат, наверное, никогда 😄

UTC рулит

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации