Question

我通过从SQL Server 2012导出数据帮助了一个同事。我输入手动查询，然后将结果复制/粘贴到Excel表格中，然后我与他分享。我制作的摘录将是一个excel文件，将手动分析。无需自动化。

我尝试做的是在导出按天分组的订单统计信息时尝试最佳做法，尝试更好地学习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）我理解：

A由SQL处理为类型Date，而B和C是字符。
B和C因时区处理而有所不同。

但我不明白：

B和C如何处理时区？
复制/粘贴到Excel时有什么实际区别？
如果我使用另一个我应该考虑的语言环境与同事共享此脚本，是否存在实际差异？
是否应该选择其中一个？

Answer 1

按顺序回答您的问题：

126使用ISO 8601日期标准，该标准表示年份方面为完整的4个字符长，而不仅仅是最后两个字符。 127使用相同的日期标准，但在时区Zulu，这是一个军事时区（比东部时间早4小时）
复制/粘贴到Excel时基本没有区别。打开Excel文档时，默认单元格格式为“常规”。将任何这些日期类型粘贴到Excel中时，它会将选项A注册为数字（在本例中为41270），并根据查询中预先存在的格式将其转换为日期格式。选项B和C将首先注册为文本，但由于它们采用日期格式（即它们具有“/”标记），Excel也可以将这些注册为日期并相应地更改格式。
< / LI>
只要您与脚本共享的人使用T-SQL，这不会导致问题。 MySQL或其他变体可能会引发问题。
CAST(createdat as date)是最佳选择（IMO）

来源：

SQL Conversion Types

ISO 8601 Details

Zulu Time Zone

将datetime作为日期从sql server导出时CONVERT vs CAST

1 个答案: