问DateTime，the Epoch和DocumentDb

EN

首先，更新: DocumentDB现在支持字符串和数字的范围索引。您必须正确设置索引才能正常工作。

现在，给你一个推荐。我已经成功地将ISO-8601时间戳存储为字符串。这是DocumentDB SDK用于处理DateTime的默认格式，因此它比转换为整数要少。

ISO-8601日期/时间字符串具有几个符合您需要的属性。

1. α-数字排序顺序是按时间顺序排列的，因此它与使用>、<、>=、<=的查询子句以及假设您有一个适当精度的范围索引(-1表示完全精度)之间的关系非常好；
2. 他们是人类可读的，所以如果你浏览一个表格，数据是有意义的；
3. 这种格式允许指定较低粒度的日期/时间。例如，你应该说" 2015 -03“是指3月，或者"2015-03- 24”是指2015年3月24日。然后，您可以使用此筛选器"startedOn >= 2015-03-24和startedOn < 2015-03-25“发出查询，查找从2015年3月24日开始的所有内容。由于字符串比较的性质，即使startedOn存储为一个完整的ISO-8601字符串，比如"2015-03-24T12:34:56.789Z“，也是有效的。

我已经写过这种方法，这里。

Teo的回答是正确的，除了我认为它是“可靠的”之外，数十亿的Microsoft、LibreOffice和Lotus1-2-3电子表格的使用时间可能远远超过Unix时间的使用。或者苹果的可可设备和电脑有了自己的时代。

请注意，几十个不同的时代已被各种计算机环境所使用。Unix时间远非独处，甚至不是主导地位。

也要注意，没有确切的Unix时间这样的东西。变化包括使用整秒、毫秒、微秒或纳秒。

在可能的情况下，使用日期-时间精明的数据类型。一定要研究和实验，以清楚地了解它的行为。

在不可能使用数据类型的情况下，回退到使用各种ISO 8601格式的字符串。这些标准格式中有些是按字母顺序排序的，特别是对于仅用于日期的值:YYYY。

在我所知道的每一个日期时间跟踪系统中，都忽略了闰秒。他们的目的是让我们每小时的时钟与日历一起摇摆，因此为了商业目的，闰秒在某种意义上是被忽略的。

约会时间的工作是令人惊讶的棘手和滑溜溜的业务。搜索StackOverflow以发现许多问题。尽量避免使用自己的解决方案。特别是对于C#，请查看野田时间库。

根据我的经验，我没有遇到比UNIX时代更“既定”的标准。尽管如此，以前已经讨论过时间存储的一些体系结构/技术方面：Java和MySQL中的时间戳和时区转换。

我想问你为什么要冒险使用你自己的约定？这是一个风险，因为:如果有一段时间你想在你的日数中增加时间，也许你可以根据人出生当天的具体时间来订购他们。这个问题可以扩展到:如果某个时候您想要度量更一般或更细粒度的时刻，那么您将不得不将整个特性(可能贯穿应用程序的许多层)转换为更通用的机制/约定。另一个(类似的)问题是:你总是为数据库中的人测量一生中一次的事件，还是他们能够创建新的、无限制的事件？随着事件数量的增加，碰撞的风险也会增加，一天的计数将不像以秒或毫秒为单位的时间戳那样合适。

UNIX时间基本上是无处不在的，在大多数编程语言中，您都有获得它的特殊方法。在我的项目中，我将始终支持和实现的计时体系结构是：http://www.currentmillis.com/tutorials/system-currentTimeMillis.html。

​

​

正如我在回答上述问题时所指出的，自UNIX时代以来将时间存储为毫秒的优点是：

• 架构清晰:服务器端与UTC一起工作，客户端通过其本地时区显示时间。
• 数据库简单性:存储一个数字(毫秒)，而不是像DateTimes这样复杂的数据结构
• 编程效率:在大多数编程语言中，您的日期/时间对象能够在构造时从Epoch起占用毫秒(这允许自动转换到客户端时区)。

因为你提到了C#，所以我想到了DateTime.MinValue。这将基本上是00年(午夜，1月1日)。

此外，这将是一些代码，可以让您从您选择的参考日期(无论是什么)获得millis，但请注意，1900年仍然与.NET的‘时代’(DateTime.MinValue)不同。

// Unix Epoch
(DateTime.UtcNow - new DateTime (1970, 1, 1)).TotalMilliseconds
// NTP Epoch
(DateTime.UtcNow - new DateTime (1900, 1, 1)).TotalMilliseconds