主页 / dba / 问题 / 204344
Accepted
pmdci
Asked: 2018-04-19 07:42:36 +0800 CST

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

  • 772

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

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

假设英国的用户创建了一个任务，截止日期为 2018 年 4 月 20 日。4 月 19 日 23:30（英国时间），圣彼得堡的一位用户打开了任务。然而，由于在圣彼得堡已经是 4 月 20 日，因此看起来任务已经完成，但实际上尚未计划运行。

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

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

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

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

我错过了什么吗？

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

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

时区计算工作流程

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

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

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

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

sql-server datetime

1 个回答

  1. Best Answer

    使用支持时区详细信息的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()函数获取服务器的当前时间，包括服务器时区。

    • 5

相关问题