2016-03-24 1 views
0

Я помогаю коллегу с экспортом данных из SQL Server 2012. Я печатаю ручные запросы, а затем копирую/вставляю результаты в лист Excel, который я затем передаю с ним. Экстракт, который я делаю, будет файлом excel, который будет проанализирован вручную. Нет необходимости в автоматизации.CONVERT vs CAST при экспорте даты и времени в качестве дат с сервера sql

То, что я пытаюсь сделать, - это урегулирование наилучшей практики при экспорте статистики заказа, сгруппированной по дням, с целью лучшего изучения SQL. У меня есть поле типа datetime, и я хочу преобразовать его в какой-то формат даты. В моем языке типичный формат даты - YYYY-MM-DD. Иногда я могу поделиться своим скриптом с другими, у которого может быть другой язык. Я нашел три утверждения, которые, похоже, дают мне одинаковые значения.

select top 1 
createdat 
, CAST(createdat as date)   as A 
, CONVERT(char(10), createdat,126) as B 
, CONVERT(char(10), createdat,127) as C 
from dbo.[Order] 

приводит к

createdat    |A   |B   |C 
2012-12-27 08:23:32.397 |2012-12-27 |2012-12-27 |2012-12-27 

Из ссылки TSQL MSDN (link) Я понимаю, что:

  • А обрабатывается SQL как тип Дата, тогда как В и С являются символы.
  • B и C должны отличаться в зависимости от их часовой поясности.

Но я не понимаю:

  • Как работает B и C ручки часовых поясов?
  • Какова практическая разница при копировании/вставке в Excel?
  • Есть ли практическая разница, если я разделяю этот сценарий с коллегами, используя другой язык, который я должен рассмотреть?
  • Должен ли тот или иной быть предпочтительным?
+2

А является лучшим вариантом. [Тип данных 'Date' не имеет формата отображения] (http://stackoverflow.com/questions/30032915/how-to-cast-the-datetime-to-time/30033028#30033028), отображаются только строки, представляющие даты форматы. поэтому вам будет проще просто использовать 'cast (datetime as date)'. Однако я не уверен, как Excel будет обрабатывать даты. –

+0

Мое личное мнение, понимание формата даты в формате Excel немыслимо. Лучше написать SQL в excel для импорта данных с SQL Server. Добавляя больше, copy-paste не всегда работает правильно в этом случае ... – Aditya

ответ

0

Чтобы ответить на ваши вопросы последовательно:

  1. 126 использует дату стандарта ISO 8601, который означает аспект Год быть полные 4 символов, а не только двух последних. 127 использует тот же стандарт даты, но в Часовой пояс Zulu, который является военным часовым поясом (на 4 часа раньше EST)

  2. По существу нет разницы при копировании/вставке в Excel. При открытии документа Excel форматом ячейки по умолчанию является «Общий». Когда вы вставляете какие-либо из этих типов дат в Excel, он регистрирует параметр A как число (в данном случае 41270) и на основе ранее существовавшего формата из вашего запроса преобразует его в формат даты. Параметры B и C сначала регистрируются как текст, но поскольку они находятся в формате даты (т. Е. Имеют метки «/»), Excel может также зарегистрировать их как даты и изменить форматирование соответственно.

  3. Пока человек, которому вы делитесь своим скриптом с использованием T-SQL, не должен вызывать проблем. MySQL или другие варианты могут начать вызывать проблемы.

  4. CAST(createdat as date) является лучшим вариантом (ИМО)

Источники:

SQL Conversion Types

ISO 8601 Details

Zulu Time Zone

+0

re: 1) мои штампы времени даны в формате даты и времени. Я знаю, что локальное время сервера UTC + 01: 00 прямо сейчас. Я не знаю, соблюдает ли он DST. Должен ли я вызывать коды конвертации 126 и 127, чтобы дать одну и ту же дату в конце, или они будут отличаться, если метка времени приближается к полуночи? – LudvigH

+0

Я на самом деле протестировал это, и даты все еще выглядят одинаково. Он не преобразует исходное время, основанное на предполагаемом часовом поясе. Вместо этого он просто назначает часовой пояс и предполагает, что ваше время уже находится в этой зоне. Мой тест менял время в исходном поле с '2012-12-27 08: 23: 32.397' на' 2012-12-27 23: 23: 32.397', и оба 126 и 127 все еще вернулись '2012-12-27 ' –

+0

Спасибо! Принимая ответ сейчас! :) – LudvigH

Смежные вопросы