Локализованное форматирование даты в Laravel

[kix]

Интересно, мне всегда казалось, что в PHP для локализации стандартом де-факто является расширение intl, надо заметить, что оно сильно упрощает вывод дат. В Symfony, например, эта проблема решается в расширении к шаблонизатору, которое зависит от intl.
Плюс, мне кажется, что всё-таки форматирование данных находится за пределами ответственности модели, т.е. метод getCreatedAtAttribute излишен, а код, в нем реализованный, попадает в зону ответственности вьюхи.

[kix]

И кстати, зачем суффикс ...Attribute в геттере? Разве не любое значение, возвращаемое геттером, будет являться атрибутом объекта?

[Khaperets]

Если заглянуть во внутренности Laravel, то можно увидеть, что модель Illuminate\Database\Eloquent\Model ищет метод «getНашАтрибутAttribute».
Подробнее: github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L2499

[kix]

А, ясно, это Ларавеловские штуки то есть. Спасибо за ссылку, теперь понятно.

[Khaperets]

Всегда пожалуйста)

[Khaperets]

К примеру, многие пишут приложение в связке с AngularJS (либо другие frontend-фреймворки), то контроллер отдает данные в json-формате.
Если во всех контроллерах циклически обрабатывать модели, где нужно преобразовать даты — получится большое скопление дублирующегося кода.
А в проектах на подобии блог/информационный портал/соц. сеть и т.д. — таких мест будет очень много.

[kix]

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

[Fesor]

Откройте для себя jms/serializer

[MaximAL]

Сам частенько реализовывал такие вещи серверно, но сейчас практически уверен, что локализация даты — задача клиента.
Особенно сейчас, когда есть семантичный и удобный тег <time>.
Даже простенькую библиотечку для этого написал — https://github.com/maximal/time.js/.
Есть ещё всякие штуки потяжелее: moment.js, например.

[Khaperets]

Не задумывался над этим ранее… Действительно, лучше формат даты делать на стороне клиента (тем более можно подхватить часовой пояс и корректировать время от его значения). Круто, нужно будет попробовать. Только нужно сделать генерацию json-файла с необходимыми переводами на различные языки.

[Amega]

Это как раз то, чего давно не хватает, и что давно просят добавить, в моей библиотечке localized-carbon. Сейчас она только умеет локализовывать разницу во времени, типо «3 часа назад», «5 лет назад» и т.д.

[roodz]

это умеет оригинальный carbon

[Fesor]

А в 2014-ом умел?

[roodz]

Тогда было бы великолепно на github в описании к пакету написать его применимость относительно текущего положения дел в самом carbon.

[AmdY]

Спасибо, хорошее решение, только пару нареканий по стилю.
Для работы с датой стоит использовать имеющуюся библиотеку Carbon и не стоит вешать это на get*Attribute чтобы не сломать поведение в других местах. Это логика отображение и её нужно делать во вьюхе или навешивать через Decorator-Presenter.

[Khaperets]

Спасибо за полезный комментарий!