Американские пользователи также путают день и месяц в таких датах, как 01/02/2013

Почти везде за пределами Соединенных Штатов, когда короткие даты, например. 01/02/2013, отображаются на экранах компьютеров, пользователь не может быть уверен, что первые две цифры представляют день или месяц . Это первый январь или февраль?

Это большая проблема для людей за пределами Соединенных Штатов, поскольку они регулярно встречаются с обоими форматами и не могут знать, адаптировалась ли система к их языку или застряла в американском формате. Но я полагаю, что американские пользователи видят в основном американский формат (потому что многие, если не большинство, информационные системы построены или для американцев). Что мне интересно, ли запущены американские пользователи в этом сценарии ?

Если вы можете указать на некоторые доказательства или исследования, отлично. Если нет, я соглашусь на ваш опытный опыт.

Примечание. Я не прошу о прекрасном решении назвать месяц, например. 21 мая 2013 года. Я спрашиваю о случаях, когда должен использоваться короткий формат даты.

75 голосов | спросил Dvir Adler 21 Mayam13 2013, 10:18:42

5 ответов


74

У меня нет указателя на опубликованные исследования, но, по моему опыту, народ США всегда будет считать формат MM /DD /YYYY США, если они сознательно не используют сайт, не принадлежащий США, и уже знают о потенциальных различиях .

Если вам нужно использовать только цифры, то формат, который вызывает наименьшую путаницу в разных культурах по моему опыту, - это YYYY-MM-DD, поскольку он отличается от обоих значений по умолчанию и не страдает от каких-либо предположений.

Тем не менее, используя сокращенное трехмесячное имя месяца, это только один дополнительный символ - аргумент размера для использования чисел обычно фиктивный.

ответил adrianh 21 Mayam13 2013, 11:49:39
11

См. ISO 8601 (например, http://en.wikipedia.org/wiki/ISO_8601 )

yyyy-mm-dd hh: mm: ss

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

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

Я обнаружил эту схему датирования несколько десятилетий назад, глядя на календарь Star Trek, и увидел, что stardates были yyyymm.dd (Примечание: я смотрел календари, а не вещи Star Trek.)

Я американец с легкой дислексией. Я видел (или воспринимал) достаточно дат, которые были написаны «назад», что я мог и никогда не мог вспомнить, какой порядок мы ожидаем, предположим, они означают, что дни (или годы) также составляют 1-12. (Я также избегаю «/», так как они заставляют дату выглядеть запутанной.)

Я использую год-месяц-дату как с помощью, так и с использованием дефисов или пробелов; и день, год, месяц, где указаны день и месяц. Это по моему выбору - ISO 8601 просто дает мне задний аргумент - в случае, когда мне когда-нибудь понадобится.

ПРИМЕЧАНИЕ. Некоторые программы могут использовать, например, «мм» в течение минут, «ММ» за месяц в цифрах и «ММММ» за месяц, указанный в тексте; «hh» может означать 12 часов, а «HH» может означать 24 часа. Все эти коды в их собственном программном обеспечении подчиняются прихоти программиста (ов).

ответил Grant 18 WedEurope/Moscow2013-12-18T02:38:34+04:00Europe/Moscow12bEurope/MoscowWed, 18 Dec 2013 02:38:34 +0400 2013, 02:38:34
4

Возможно, сначала начните с года? Сначала вы выбросите кого-то, но по уважительной причине. Я никогда не видел структуру YYYY-DD-MM в дикой природе, только YYYY-MM-DD. Казалось бы, для пользователей, что это может быть не так, как они привыкли видеть дату, но это делает ожидания ясными. Вы также можете найти ключ поблизости для любого формата даты (если это так, диаграмма событий).

ответил Zak 23 Maypm13 2013, 17:22:33
4

Да, мы делаем; отсюда Объявление публичной службы от xkcd на "... правильный способ записи числовые даты ".

ответил Kenny Evitt 28 Mayam13 2013, 04:43:38
0

Вы можете использовать международно узнаваемый формат dd-MON-yyyy, чтобы избежать путаницы. Например, см. http://www.oracle.com/webfolder/ux/middleware/richclient/index.html?/webfolder/ux/промежуточное программное обеспечение /richclient /guidelines5 /commonFormats.html

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

В качестве альтернативы вы можете добавить на экран обозначения, в которых указывается, что даты указаны в формате США (и приводятся примеры).

В идеале UX должен позволять пользователям вводить формат даты, используя то, с чем им удобно, и выполнять преобразование «на лету», а затем сохранять дату в формате, который может быть отображен обратно в соответствии с предпочтениями пользователя. Рекомендации UX также должны позволить пользователю выбирать их формат даже в рамках соглашения о локали.

Например, воскресенье, 28 января 2011 г. Также можно использовать сокращенный формат, например, с января по 28-11 января или 28 января. Как правило, если аудитория просмотра является международной или, вероятно, будет избегать любого формата отображения номера, будет более безопасным, хотя это, по-видимому, вне вашего прецедента, поэтому допустимо будет 01-28-2011.

ответил uobroin 22 Mayam13 2013, 02:52:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132