Я установил свой тип данных на> дату, когда я создавал свою таблицу. Я могу хранить даты в формате mm/dd/yyyy
, но не dd/mm/yyyy
.
Как я уже упоминал в своем комментарии, даты не сохраняются с их отображением форматом - фактически вы можете сказать, что даты не имеют формата отображения - только строковое представление дат имеет формат отображения.
Всякий раз, когда вы имеете дело со строковыми литералами, представляющими значения даты и даты и времени на сервере SQL, используйте ISO 8601 формат даты и времени (yyyy-MM-ddTHH:mm:ss
или yyyyMMddTHHmmss
).
SQL Server гарантирует должный анализ этого строкового представления в значения даты / времени без неоднозначности.
Обратите внимание на разделитель T
между датой и временем. Существует очень похожий стандартный формат, где T
заменяется пробелом, но тип данных DateTime
имеет ошибку при разборе этого формата - и равен зависящий от культуры (обратите внимание, что DateTime2
не имеет этой ошибки) - и это еще одна причина , почему вы никогда не должны снова использовать datetime.
Когда вы используете строковый литерал, такой как '25/03/2018'
, человеку легко увидеть, что он обозначает March 25th 2018
, но SQL Server выдаст ошибку , пытаясь разобрать эту строку в дату, если текущее значение DATEFORMAT
не равно DMY
.
Однако SQL Server будет всегда правильно анализировать строковое представление ISO 8601 независимо от локальных настроек или предыдущих set dateformat
или set language
операторов и т. Д. '. '2018-02-01T15:40:50'
будет всегда будет проанализировано February 1st 2018, 3:40:50 PM
.
Если не указано иное, как писал Мартин Смит в своем комментарии, значение по умолчанию dateformat
зависит от настроек языка по умолчанию для текущего имени входа , поэтому запрос, который работает для одного имени входа, может вызвать ошибку для другого. войти в систему - и это еще одна веская причина никогда доверять строковому представлению даты и времени для конкретной культуры.