Какой формат даты выбрать: практическое руководство для UX/UI дизайнеров

[Quaziir]

Когда пользователь видит 01/05/12...
YY/MM/DD Японский стандарт с 5 января 2012 год

Наверное тут подразумевалось 12 мая 2001?

[alex_gour]

точно, описка. Спасибо огромное

[Evengard]

Ненавижу относительные даты, особенно в чатах...

Ищешь какое-то сообщение в чате, пытаешься понять когда это обсуждалось... "месяц назад". Ну и толку мне от этой информации?

[skymal4ik]

Плюсую, раздражает такое, особенно для дат в далеком прошлом.

Год назад - это ровно год назад? День в день или с какими-то оговорками? В этом же месяце год назад? А если это были начало или конец месяца? А время?

Но самое отвратительное для меня - недавно. Недавно относительно чего, блин? Кто устанавливает рамки этого недавно?!

[SpiderEkb]

Основной плюс формата ISO в том, что он в строковом (YYYY-MM-DD) или числовом (YYYYMMDD) обеспечивает правильный порядок сортировки и корректное сравнение на больше-меньше

[nin-jin]

Про относительные даты тут более подробный анализ: https://mol.hyoo.ru/#!section=docs/=2uuc9_qia88j

[aborouhin]

Вот не надо текстовых дат в интерфейсе, пожалуйста. Поле ввода даты должно позволять мне быстро ввести 8 цифр и всё (а разделители должны подставиться автоматически, тоже бесит, когда не так). А в каком порядке идёт день с месяцем, должно зависеть от моей локали.

[SpiderEkb]

Вот только в поле даты вы вводите текст (или как цифры). А дальше уже идет подстановка разделителей, валидация, преобразование деты во внутренний формат и т.п.

В той же БД она будет хранится не текстом и не цифрой, а как DATE. И в коде с ней работаем как с типом DATE (где он поддерживается, конечно), со всей арифметикой - добавить/вычесть нужное количество месяцев, преобразовать у нужный строковый/числовой вид и т.п.

[aborouhin]

Ну речь-то именно про представление в интерфейсе.

[sourbarberry]

Про представление, а не ввод. Не всегда UI должен 1 в 1 повторять строчки в БД

[alex_gour]

речь не про ввод, а вывод для информации (как на скрине)

[aborouhin]

Довольно странно, если отображаться в поле для ввода даты будет "22 Mar 2025", а при вводе даты в это поле будет использоваться другой формат. Я вот и не догадаюсь, что можно ввести цифры туда, где отображаются буквы.

[alex_gour]

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

[sourbarberry]

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

[alex_gour]

так указан формат в зависимости от локали, но так же прописан вывод, что если локаль размыта то для недопущения ошибок проще прописывать по ISO

[tvin]

Проблема не стоит того времени, которое затрачено на чтение статьи. Банальщина...

Было бы круто добавить кейсов, когда ошибки в восприятии даты приводили к нежелательным последствиям. А лучше написать отдельную статью, если конечно такой материал найдется. Как вариант, можно поискать в истории авиации. Там бывают интересные истории в духе -- пилот неправильно вбил высоту -- без лишних предисловий, мужчина умер, а с ним еще 350 пассажиров.