< input > элементы типа datetime-local создают элементы управления вводом, которые позволяют пользователю легко вводить дату и время, включая год, месяц и день, а также время в часах и минутах.

Пользовательский интерфейс элемента управления в целом варьируется от браузера к браузеру. В браузерах без поддержки они изящно деградируют до простых < input type="text" > элементов управления.

Пользовательский интерфейс элемента управления в целом варьируется от браузера к браузеру. В браузерах без поддержки они изящно деградируют до простых < input type="text" > элементов управления.

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

Из-за ограниченной поддержки браузером datetime-local , а также различий в том, как работают входные данные, в настоящее время может быть лучше всего использовать фреймворк или библиотеку для их представления или использовать собственный пользовательский ввод. Другой вариант — использовать отдельные входы date и time, каждый из которых поддерживается более широко, чем datetime-local .

Самое простое использование < input type="datetime-local" > включает в себя комбинацию базового элемента < input > и < label > элемента, как показано ниже:

Вы можете использовать атрибуты min и max для ограничения даты/времени, которые может выбрать пользователь. В следующем примере мы устанавливаем минимальную дату 2017-06-01T08:30и время и максимальную дату, и время 2017-06-30T16:30:

< input type="datetime-local" > не поддерживает атрибуты размера элемента управления формы, такие как size . Вам придется прибегнуть к CSS для настройки размеров этих элементов.

Одна вещь, которую datetime-local тип ввода не предоставляет, — это способ установить часовой пояс и/или языковой стандарт элемента управления датой/временем. Это было доступно в datetime типе ввода, но теперь этот тип устарел, так как был удален из спецификации. Основные причины, по которым это было удалено, — это отсутствие реализации в браузерах и проблемы с пользовательским интерфейсом. Проще просто иметь элемент управления (или элементы управления) для установки даты/времени, а затем иметь дело с локалью в отдельном элементе управления.

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

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

По умолчанию < input type="datetime-local" > никакая проверка не применяется к введенным значениям. Реализации пользовательского интерфейса обычно не позволяют вам вводить что-либо, кроме даты/времени, что полезно, но пользователь может по-прежнему не вводить значение и отправлять или вводить недопустимую дату и/или время (например, 32 числа). Апреля.

Вы можете использовать min и max для ограничения доступных дат, а также вы можете использовать required атрибут, чтобы сделать ввод даты/времени обязательным. В результате поддерживающие браузеры будут отображать ошибку, если вы попытаетесь отправить дату, выходящую за установленные границы, или пустое поле даты.

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

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

Вторая проблема самая серьезная; как мы упоминали ранее, при datetime-local вводе фактическое значение всегда нормализуется к формату YYYY-MM-DDThh:mm. С другой стороны, при текстовом вводе браузер по умолчанию не распознает, в каком формате должна быть дата, и существует множество различных способов, которыми люди пишут дату и время, например:

Один из способов обойти это - поместить pattern атрибут на ваш datetime-local ввод. Даже если datetime-local ввод не использует его, резервный текстовый ввод будет. Например, попробуйте просмотреть следующую демонстрацию в неподдерживающем браузере:

Если вы попытаетесь отправить его, вы увидите, что браузер теперь отображает сообщение об ошибке (и выделяет ввод как недействительный), если ваша запись не соответствует шаблону nnnn-nn-nnTnn:nn, где n число от 0 до 9. Конечно, это не так. не мешать людям вводить неверные даты или неправильно форматировать дату и время. И какой пользователь поймет шаблон, в который ему нужно вводить время и дату? У нас все еще есть проблема.

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

JavaScript использует плавающие запятые двойной точности для хранения дат, как и со всеми числами, а это означает, что код JavaScript не будет страдать от проблемы Y2K38, если не используется целочисленное принуждение/бит-хаки, потому что все битовые операторы JavaScript используют 32-битные целые числа с дополнением до 2s со знаком.

Проблема связана с серверной частью вещей: хранение дат больше 2 ^ 31 - 1. Чтобы решить эту проблему, вы должны хранить все даты, используя либо 32-битные целые числа без знака, 64-битные целые числа со знаком, либо числа с плавающей двойной точностью. точки на сервере. Если ваш сервер написан на PHP, исправление может быть таким же простым, как обновление до PHP 8 или 7 и обновление вашего оборудования до x86_64 или IA64. Если вы застряли на другом оборудовании, вы можете попробовать эмулировать 64-битное оборудование внутри 32-битной виртуальной машины, но большинство виртуальных машин не поддерживают этот вид виртуализации, так как может пострадать стабильность и определенно сильно пострадает производительность.

На многих серверах даты хранятся как числа, а не как строки — числа фиксированного размера и независимого от формата (кроме порядка байтов). После 10 000 года эти цифры будут немного больше, чем раньше, поэтому на многих серверах не возникнет проблем с формами, отправленными после 10 000 года.