SQL Server 日期时间问题。 美国与英国？

Question

在我的测试数据库上，日期以 DD/MM/YYYY 格式显示。 我所说的显示是指当您右键单击并在 Management Studio 中打开表时，返回的数据以 DD/MM/YYYY 格式显示。

有趣的是，当我编写 T-SQL 来检索记录时，我必须输入 MM/DD/YYYY 格式才能获取正确的数据。 无论如何，我可以将其与 DD/MM/YYYY 格式对齐吗？

Answer 1

您可以使用设置语言来选择 SQL Server 预期在查询中（我认为 Management Studio 使用客户端计算机的区域设置进行显示，但不确定）。 但是，我建议使用参数传递值，而不是将它们嵌入到查询语句中。 如果使用参数，则不会遇到任何问题。 一切都得到照顾。

set language us_english
declare @d datetime = '1929/12/18'

set language british
declare @d datetime = '1929/12/18' -- fails

更改服务器默认语言：

declare @langid int = (select langid from syslanguages where name = 'british')
exec sp_configure 'default language', @langid
reconfigure with override

Answer 2

就我个人而言，我总是使用 YYYY-MM-DD 格式（或 YYYYMMDD），因为它不是特定于文化的，而且，我想它对我很有吸引力，因为它是“合乎逻辑的”（特别是当后面跟着一个时间）。

[编辑：我只是在谈论我在 SQL 脚本中放入的内容以确保兼容性，而不考虑服务器设置，而不是 SQL Server“显示”的内容]

Answer 3

您可以为每个SQL Server 登录设置默认语言。 不太记得了，但大概是这样的：

sp_defaultlanguage @loginame = 'LoginName', @language = 'Language'

Answer 4

如果您以 DATETIME 格式传递，

dd MMM yyyy

例如，

"11 JUL 2009"

则月份和日期永远不会有任何歧义，因此您永远不会遇到问题

Answer 5

在几乎所有情况下，解决此问题的正确方法就是永远不要将日期视为字符串。 如果您传入参数或使用（类型化）列值，则服务器的文本转换根本就不是一个因素。 除了避免 i18n 问题之外，这还可以减少注入攻击面。 而且它也节省了一些 CPU 周期；-p

如果您使用 EXEC 来执行动态 SQL，那么这同样应该通过 sp_ExecuteSQL 进行参数化。

Answer 6

我尝试尽可能使用 ODBC 规范形式的日期
{d 'yyyy-mm-dd'}
这样我就知道sql server将如何解释它。
它在 TSQL 中工作得很好。

Answer 7

将其添加到您的 web.config 文件中：

</system.web>
    <globalization culture="en-US" uiCulture="en-US" />
</system.web>

或者您可以在页面上添加此语句：

<%@ Page uiCulture="en-US" culture="en-US" %>

希望这有帮助。