Приведение даты к формату — на бэкенде или фронтэнде?

Question

[Роман Сарваров]

Я делаю сайт в связке Laravel + Vue.js.
Laravel возвращает данные из базы, среди которых есть значения в виде даты и времени.
Пользователю в браузере нужно выводить эту дату в определенном формате, например "d.m.Y H:s".
Как вы считаете, лучше делать это на стороне API (с помощью Carbon) или на фронтэнде (с помощью какого-нибудь momentjs)?
Как я понимаю, последнее медленнее, но более управляемо в будущем.

Comments

[Вадим]

Если пользователю нужно вывести эту информацию строкой - то лучше отсылать с бэка.
Работа с датой на клиенте - очень тонкая и капризная штука, если работать не со строкам, а с объектом Date, так как он учитывает часовой пояс, выставленный на устройстве пользователя. И если на телефоны ещё можно более менее положиться, т.к. в подавляющем (но всё же не на 100%) случае используется время сети, то с персональными пк всё сложнее.

[WapSter]

У меня на текущей работе этой задачей в основном занимается бэк, но бывают специфичные задачи и используется moment

[Sanes]

Вадим, давно видели ПК без настроенного времени?

[Вадим]

Sanes,
1. вышел из офиса разработчиков
2. зашёл в офис менеджеров
3. увидел пк без настроенного времени

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

[Sanes]

Вадим, значит у них интернета нет или отключили синхронизацию сознательно.

[Вадим]

Sanes, А вот и не угадали.
Стоит другой часовой пояс.

[Sanes]

Вадим, значит нормально всё.

[Вадим]

Sanes, а у клиента на мобиле индия стояла.
Прописная истина "никогда не доверяй клиентскому окружению" не спроста есть на свете.

[Sanes]

Вадим, если это просто для информации, то пофигу.

[Вадим]

Sanes, Если это информация о времени наступления работ, о времени выполнения заказа и дальше ещё длинный список, который, мне кажется, покрывает 100% случаев, т.к. если Вам нужно вывести дату на клиент, значит она там реально нужна, то врятли пользователю будет пофигу.

[Sanes]

Вадим, для информации, это значит для не критичной информации в прошедшем времени. Например время публикации статьи. Плевать, что там написано. Разница в 24 часа роли не играет.

[Вадим]

Sanes, Ну, не знаю, как Вам, а в современном мире дата публикации статьи требует наибольшей свежести, чтобы быть релевантной для пользователя. Если это статья с рецептом готовки блинчиков, то ещё может быть, а в остальном, такое.
А если ещё и на сео хотите повлиять и на паттерны поисковой выдачи, то лучше чтобы дата публикации статьи сразу приходила в нужном формате в разметке.

[Северное Сияние]

WapSter,

У меня на текущей работе этой задачей в основном занимается бэк

вы отдаете дату с сервера сразу в том часовом поясе, в котором находится клиент??

[WapSter]

Северное Сияние, нет на сервере по UTC все операции записываются, на фронт отдается в том же виде и уже на фронте приводятся к текущему часовому поясу пользователя. Но такое редко нужно по этому в основном на бэке GMT+3.

[shurshur]

Sanes, сравнительно недавно в России дважды меняли часовые пояса. Пользователи, у которых не было обновления часовых поясов, исхитрялись как могли, чтобы частики в углу экрана показывали то же самое, что часики на стене. И вообще, пользователи часто настраивают не так, как надо, а "работает-и-ладно". У них может быть включено время по Сантьяго (UTF+6), а чтобы оно не слетало каждый день вырублена синхронизация. Ну или синхронизация в принципе не работает по каким-то причинам сама по себе. Короче, проблема на самом деле гораздо серьёзнее, чем можно было ожидать, хотя сейчас намного лучше, чем ещё лет 10 назад (когда штатный time.windows.com не работал чаще, чем работал, обновления никто не ставил и неправильный год в дате не приводил к массовым отваливанием сайтов из-за короткоживущих SSL-сертификатов LetsEncrypt).

[Sanes]

shurshur, это исключение. Если для проекта надо показывать время пользователя, то надо делать на фронте.
Например графики. Удобно будет пользователю ориентироваться в UTC если у него время отличается?

[shurshur]

Sanes, я не говорю что это плохо и вообще не давал никаких советов. Я говорю о том, что далеко не всегда локальное время пользователя действительно настроено нормально. С другой стороны, если на всех сайтах фронт будет одинаково искажать время, то пользователь быстрее напряжётся и поищет у себя проблему, что, наверное, не так уж и плохо.

[Sanes]

shurshur, часы всегда на виду. Если он до сих пор не напрягся, то мне его жаль.

[shurshur]

Sanes, я сам лично помогал пользователям ставить минское время во времена изменения часовых поясов. Увы, это было вынуждено.

Кстати, ещё встречающаяся фигня - в Linux часто настроено по умолчанию хранить системное время в UTC, а в Windows - локальное. При перезагрузках из одного в другое время всё время прыгает, что пользователь не замечает, пока у него не ломается синхронизация по любой причине (например, отсутствует интернет). Неприятно, в общем. Я из-за этого подкручивал время в Linux на local в былые времена, когда дома не было доступа в Internet, потому что домашним компьютером пользовалась вся семья.

[Sanes]

shurshur, всё это из разряда "а если у пользователя IE6?"

[shurshur]

Sanes, ещё раз, я не советовал учитывать наличие у пользователя IE6. Я просто рассказываю, что компьютеры с плохо выставленным часовым поясом будут встречаться всегда, отрицать их существование бессмысленно.

[Роман Сарваров]

Спасибо, очень интересно.
Как я понимаю, мнения тут разнятся, но большинство всё-таки считает, что за отображение, в т.ч. времени, отвечает фронт-энд.

Answer 1

[Alex]

С бэка отправляется дата по UTC.
На фронте форматируется и выводится уже в локальном часовом поясе.
Для форматирования не нужны сторонние библиотеки (Зависит от браузеров которые вам нужно поддерживать)
https://developer.mozilla.org/ru/docs/Web/JavaScri...

Answer 2

[Sanes]

moment.js прекрасно справится на фронте. Фильтры соответствующие в Vue добавьте и форматируйте, как вам удобно. Насколько помню, она может подхватить время браузера.

Answer 3

[Константин Б.]

Все по разному делают, я в том числе, но придерживаюсь мнения что бекенд не должен знать о том в каком виде пользователь видит дату, его задача отдать ее в UTC, а уже на фронте все это дело стилизуется