选择合适的数据类型时的时区注意事项

Question

我们目前正在为我们的定制应用程序开发一个任务管理系统。经过深思熟虑，我们得出的结论是，我们只需要用户指定任务的截止日期。

我想知道当英国的用户添加任务并且圣彼得堡的用户看到它时它会如何工作，考虑到圣彼得堡比英国早至少 2 小时。

假设英国的用户创建了一个 20/Apr/2018 到期的任务。4 月 19 日 23:30（英国时间），圣彼得堡的一位用户打开了任务。但是，由于在圣彼得堡已经是 20/Apr，看起来任务已经完成，但实际上还没有安排运行。

如果日期字段实际上是 type date，我很确定圣彼得堡的用户会看到标记为过期的任务，因为他结束时已经是 20/Apr。

我见过其他几个任务工具，而且几乎所有工具都只允许任务的截止日期（而不是时间）。然而，我想知道其他系统如何处理此类问题，或者他们是否根本不打扰。

所以客观地回答我的问题：

• 我们承认这种差异并接受它。如果任务将于 4 月 20 日到期，并且在澳大利亚已经是 4 月 20 日，但在加利福尼亚州尚未到期，我们只接受澳大利亚用户将任务视为迟到而加利福尼亚用户将其视为“进行中”。
• 我认为解决这个问题的唯一方法是在datetime字段中捕获日期（即使我们不允许用户输入时间），然后还允许定义时区。

我错过了什么吗？

编辑：为了回答有关我们是否希望任务的截止日期遵循查看任务的用户的时区或创建任务时的固定时区的问题，我们选择了固定时区。因此，任务将设置为英国时间 20/Apr 到期，只有在英国时间达到 YYYY-04-20 00:00:00.00 时才会到期。

为了支持这一点，我们将允许用户在创建任务时单击截止日期字段旁边的小图标，允许他们选择时区。时区将根据以下工作流程设置为默认值：

我们将为用户的帐户页面创建两个设置，允许用户：

• a) 切换应用程序的选项以尝试从客户端自动获取其时区。

• b) 让他们选择默认时区的选项。

基于这个要求，我们几乎可以得出结论，date数据类型是不可能的。现在对我来说不是 100% 清楚的是我们应该选择 a datetime2（我总是使用datetime2而不是datetime）还是 a datetimeoffset。

Answer 1

使用支持时区详细信息的datetimeoffsetSQL Server 数据类型：

USE tempdb;

DROP TABLE IF EXISTS dbo.timetest;
CREATE TABLE dbo.timetest
(
    t datetimeoffset(0) NOT NULL
);

INSERT INTO dbo.timetest(t)
VALUES ('2018-04-18 00:00:00 +03:00');

SELECT [Time at CEST] = t AT TIME ZONE 'Central European Standard Time'
    , [Time at RST] = t AT TIME ZONE 'Russian Standard Time'
FROM dbo.timetest;

结果：

?????????????????????????????????????????????????????? ?????????
? CEST时间？在 RST 的时间？
?????????????????????????????????????????????????????? ?????????
? 2018-04-17 23:00:00 +02:00 ? 2018-04-18 00:00:00 +03:00 ?
?????????????????????????????????????????????????????? ?????????

在上面的示例中，我们在俄罗斯时区插入数据，然后以中欧标准时间和俄罗斯标准时间显示它。

您可以使用该SYSDATETIMEOFFSET()函数获取服务器的当前时间，包括服务器时区。