将所有内容都存储在格林尼治标准时间(GMT)吗？

将所有内容存储为带有嵌入式偏移量的输入方式吗？

每次渲染时都会进行数学运算吗？

显示相对时间" 1分钟前"？

解决方案

回答

就我个人而言，我看不出没有任何理由不将所有内容存储在GMT中，然后使用用户本地时区显示与他们相关的时间。

如果要显示相对时间，显然我们仍然需要时间并进行翻译，但是如果我们要进行翻译，我认为GMT仍然是最佳选择。

回答

我喜欢存储在GMT中，并且只显示相对值("大约10秒钟前"，" 5个月前")。用户无需查看大多数用例的实际时间戳。

当然也有例外，单个应用程序可能会有很多例外，因此它不能是"单向"的答案。需要强大的审计能力(例如投票)的事物以及时间是讨论领域(天文学，科学研究)的一部分的系统可能需要向用户显示真实的时间戳。

但是，大多数应用程序在相对简单的时间内就更易于理解。

回答

如果不这样做，则必须存储在UTC中，在诸如夏令时之类的历史报告和行为方面……真有趣。 GMT是当地时间，相对于UTC(不是)，应遵守夏令时。

如果我们要存储本地时间，那么向不同时区的用户进行演示可能是一个混蛋。如果原始数据采用UTC格式，则很容易调整为本地值，只需添加用户的偏移量就可以了！

乔尔(Joel)在一个播客中谈到了这一点(以一种绕过的方式)，他说要以尽可能高的分辨率(搜索"保真度")存储数据，因为当它再次出现时，我们总是可以对它进行修改。这就是为什么我说将其存储为UTC的原因，因为本地时间需要针对不在该时区的任何人进行调整，所以这是很多艰苦的工作。并且我们需要存储例如在存储时间时夏时制是否生效。育。

过去，我通常在数据库中存储了两个UTC进行排序，本地时间用于显示。这样，用户和计算机都不会感到困惑。

现在，显示如下：当然，我们可以执行" 3分钟前"操作，但是只有在存储UTC的情况下，在不同时区中输入的数据才可以执行类似" -4小时前"的显示，这将使人们出来。如果要显示实际时间，人们会喜欢在当地时间显示它，并且如果要在多个时区中输入数据，则只有在存储UTC时才能轻松做到这一点。

回答

因此，我对MSSQL服务器进行了一些实验。

我创建了一个表，并添加了具有当前本地化时区(澳大利亚)的行。
然后，我将日期时间更改为格林尼治标准时间，并添加了另一行。

即使这些行以大约10秒的间隔添加，它们在SQL服务器中的间隔也为10小时。

如果没有别的，它至少告诉我应该以一种可靠的方式存储日期，这对我来说，增加了将日期存储为GMT的论点的重要性。

回答

MS Dynamics将存储GMT，然后在用户级别上了解我们相对于GMT的时区。然后，它将在我们所在的时区向我们显示项目。

只是以为我会把它扔出去，因为这是MS的一个很大的团队，这就是他们决定处理它的方式。

回答

我通常只使用Unix时间。不一定将来会安全，但是效果很好。

回答

始终存储在GMT(或者UTC)中。从那里很容易转换为任何本地时区值。

回答

乔希在上面是完全正确的，但是我有一个细微的警告要解释。在这种情况下，对于未来的事件和时区没有正确的答案。

考虑重复约会的情况。它发生在格林尼治标准时间0000(为简单起见)，即1200 NZST(新西兰标准时间)和澳大利亚悉尼的1000 AEST。

当夏令时在一个区域中生效时，约会将发生什么？应该是：

1a。如果TZ变化在
约会的"所有者"(谁
预订)，然后尝试停留在
相同的办公桌时钟时间(例如上午10:00)？
1b。如果
TZ变化是其中之一
会议与会者的区域，然后否
改变

结果：它为
其他所有人，由于
所有者TZ改变了，但是仍然存在
直到"上午10点会议"
老板关心。

'2. 如上所述，但是相反。

后果：它为会议所有者移动(上午10点的会议变为上午9点的会议，或者v / v)，这可能是预料之中的，但不方便。对于其他与会者，它将保持相同的桌面时钟时间，直到他们进行自己的TZ过渡为止。

两者都不是完美的。考虑两个约会的情况，一个约会是由A人预定的，发生在当地时间上午10点，另一个约会是由B人预定的，其中A人作为与会者出现在上午9点。如果人员A和人员B处于不同的TZ，则DST更改很容易导致他们被双重预订。

如果此时想法有些弯曲，那我就很明白。

该示例背后的意义是，要正确执行上述任何一种行为，我们不仅需要了解当地时间的UTC版本，还需要知道所有者预订时的TZ(而非偏移量)。否则，我们别无选择，只能默默地接受选项2，甚至不通知任何人，因为GMT时间不变，只有演示文稿发生了变化，事情已经发生了变化，对吧？ (不，这是陷阱，当我们上午10点的会议自行移动时，演示很重要)

我必须感谢我的同事和朋友Jason Pollock的这种见解。在此处阅读他的观点，并在此处讨论iCal和VTIMEZONE的后续讨论。

回答

与往常一样，答案是"依赖"。

这取决于我们对时间的描述以及如何将数据提供给我们。
决定如何存储时间值的关键是通过删除时区来确定是否丢失信息，以及使用户感到惊讶。

将数据存储在UTC time_t中是有一个明显的好处，它是单个int，可以快速排序并易于存储。

我认为问题已分解为特定区域：

• 历史数据
• 未来短期数据
• 未来长期数据

在每个子类上具有以下子类：

• 系统提供
• 用户提供

让我们一次看看他们。

提供的系统：我建议使用UTC运行系统，这样可以避免时区问题，并且再也不会看到信息丢失(始终为UTC)。

历史数据：这些是系统日志文件，进程统计信息，跟踪，注释日期/时间等内容。数据不会更改，并且时区描述符也不会追溯更改。对于这种类型的数据，无论将信息提供在哪个时区，都不会通过将信息存储在UTC中而丢失任何信息。因此，请删除时区。

未来的长期数据：这些事件或者在将来足够远，或者将持续发生。如果它们保持足够长的时间，则可以保证时区描述符会发生变化。此类数据的一个很好的例子是"每周管理会议"。这是一次输入的数据，有望永久保存。对于这些值，重要的是确定它是系统提供的还是用户提供的。对于用户提供的数据，时间应与创建者的时区存储在一起，否则会导致信息丢失。当时区定义更改并且时间以完全不同的值显示给创建者时，这种信息丢失变得明显！

正如Bwooce所指出的那样，创作者和观看者位于不同时区存在一些困惑。在这种情况下，我希望该应用程序指示由于从其先前位置移出时区而移动了哪些时间值。

将来的短期数据：这些数据将很快成为历史数据，或者仅在短时间内有效。例如间隔计时器，等级转换等。对于此数据，由于定义在值的创建和变为历史的时间之间变化的可能性很小，因此有可能可以放弃时区。但是，我发现这些值有成为"未来的长期数据"的坏习惯。

一旦决定存储时区，就必须注意时区的存储方式。

• 不要将时区存储为偏移量或者完整的描述符。

如果将时区存储为偏移量，那么如果时区更改，该怎么办？我们是否浏览了系统并对现有数据进行了全面更改？如果这样做，我们现在就使任何历史值都不正确。 Oracle和iCal就是很好的例子。 Oracle将时区信息存储为UTC的偏移量，并且iCal包含创建时区的完整描述符。

• 务必将其存储为名称。

这样就可以更改时区的定义，而不必修改现有的值。这确实使排序更加困难，因为如果时区数据发生更改，则所生成的任何索引都可能无效。

如果开发人员不管时区如何继续将所有内容存储在UTC中，我们将继续看到上一批时区更改遇到的问题。

在一个组织中，秘书必须在夏令时之前打印出其团队的日历，然后在更改后再次打印出来。最后，他们将两者进行了比较，并重新创建了所有已移动的约会。当然，他们错过了好几次，并且有数周的痛苦，直到达到了旧的夏令时，时间又变得正确了。

回答

我更喜欢将所有内容与时区一起存储。
客户可以决定以后应采用哪种方式呈现。
我最喜欢转换的库是PostgreSQL数据库。

回答

对我来说，将所有内容存储在GMT / UTC中似乎是最合逻辑的。然后，我们可以显示所需的每个时区的日期和时间。

一些提示：

• 如果仅将时间指定为挂钟时间并且是最主要的表示形式，则它不是绝对指定的时间。我们应该(也不能)将其转换为任何GMT表示形式。例如。每天早上9:00 AM。换句话说：这是没有(日期)时间。
• 如果保存将来约会的日期和时间，则应使用由输入时区和时间本身指定的GMT偏移量。因此，如果是夏季，例如冬天，西欧为+2：00，尽管正常(冬季)偏移为+1：00。这将解决Bwooce提到的压光机问题。
• 当然，当转换回任何特定时区的日期和时间时，在转换为GMT时使用正确的偏移量也是如此。

幸运的是，如果使用正确，(。NET)DateTime类型将为我们处理保留日历等所有繁琐的细节，并且当我们知道其工作方式时，所有这些都将非常容易。