Есть ли универсальный формат даты, который любой в мире может понять?

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

Я думал об использовании следующего формата метода для всех: Feb 02, 2011

Неоднозначная часть заключается в дифференцировании дня от месяца , если они представлены числами.

02/03 означает 03 февраля или 02 марта?

Изменив идентификатор месяца по номеру и названию, вы удалите эту неоднозначность. Чтобы ответить на ваш вопрос, ваш вариант Feb 02, 2011кажется хорошим решением.

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

Нет. Не существует общепризнанного формата даты.

ISO 8601 Определяет международный стандарт для форматов даты. Таким образом, это, вероятно, лучший компромисс. Но, как вы говорите, пользователям не всегда нравится этот формат.

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

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

В JavaScript вы можете использовать метод toLocaleString для класса Date .

Для C # вы можете использовать строку формата при использовании ToString .

Быстрый поиск Google должен показать вам, как использовать культуру на выбранном вами языке.

Я бы пошел с YYYY-MM-DD (и всегда выписывал бы четырехзначные годы и двузначные месяцы и дни). ГГГГ-ДД-ММ, насколько мне известно, встречается редко, поэтому формат ГГГГ-ММ-ДД имеет наименьшую двусмысленность, и в конечном итоге ваши пользователи поймут это. Кроме того, вы получаете тривиальное преимущество сортировки.

Можете ли вы дать каждому пользователю его / ее собственную локаль, которая затем отображает даты и другую информацию в соответствии с их местными предпочтениями?

Много раз вы можете настроить язык и использовать I18n в большинстве сред.

В общем случае вам нужно будет указать формат и значение. Это единственный способ избежать путаницы. Например, вы можете сказать «2011-02-02 (ГГГГ-ММ-ДД)». Это происходит за счет простоты и читабельности, поэтому знайте свою аудиторию.

Конечно, вы можете сказать: «Здесь и далее все даты будут в формате ГГГГ-ММ-ДД ...». Тогда появившееся позже слово «2011-02-02» будет однозначным. Это может быть более приемлемым, но опять же, знайте свою аудиторию.

Это предположение, вероятно, бесполезно, но я видел месяцы, написанные римскими цифрами. Конечно, 3 / XI / 2011 может быть 11 ноября или 3 марта, но я думаю, что первая интерпретация более естественная.

Я бы сказал, что это зависит от того, что вы делаете, насколько вы контролируете вход, и где вы его храните?

Для хранения я бы использовал то, что предложил Майк Данлавей:

ГГГГММДДЧЧММСС, где время в UTC - это путь, по которому я иду, когда у меня есть выбор, по причинам, которые вы указываете. Когда у меня нет выбора, я позволяю пользователю выбирать.

Он не оставил это как ответ, так что я буду.

Еще одна вещь: посмотрите на следующий снимок экрана того, как ввести дату истечения срока действия CC: http://www.ubercart.org/files/credit_card_checkout.jpg

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

Как я уже сказал, это зависит. Для хранения: если вы используете базу данных, проверьте, обеспечивает ли она хороший однозначный формат данных. При использовании другого метода посмотрите, помогает ли «ГГГГММДДЧЧММСС, где время в UTC». Чтобы представить его пользователю - примите во внимание, какие страны / локали могут быть вовлечены, затем выберите наиболее прямолинейный вид «Не заставляй меня думать». Также рассмотрите возможность предоставления опции.

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

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

Для хранения даты и времени в базе данных используется универсальный формат - UTC (координата универсального времени).

К сожалению, весь интеллект в международном вычислительном мире не может взломать этот орех.

Ни Microsoft, ни другие поставщики не рассматривают возможность добавления маски даты, при которой месяц будет выглядеть заполненным нулями, почти как день, но в виде трех цифр. Принятие практики поможет продвинуть новую серию измененных форматов дат, которые математически эквивалентны, но при этом их будет легко идентифицировать и отличить в любом из традиционных форматов дат. Это:

• 0MM-DD-YYYY, например, 002-03-2016 за февраль 03,2016

• ДД-0ММ-ГГГГ, например, 03-002-2016 на 03 февраля 2016 года

• ГГГГ-0ММ-ДД, например, 2016-002-03 на 2016-02-03

• ГГГГ-ДД-0ММ, например, 2016-03-002 (если кто-то хотел его использовать!)

Кажется, слишком легко это исправить ... Я думаю, просто не очень хорошо продается.