DateTime，Epoch和DocumentDb

所以我读了这个非常有趣的博客，关于在Azure DocumentDb中使用datetime 。 问题是，目前，Azure DocumentDb不支持日期时间字段的范围搜索。 原因是DocumentDb基于json并且没有日期时间类型，因此通常将其放在xml日期时间格式的字符串中。

（显然Mongo没有那个问题，它的bson格式添加了datetime类型（以及其他））

无论如何，该文章描述了在一个纪元（unix）时间内将日期时间存储在json中，基本上将日期时间存储为自01-01-1970以来的秒数。 时代的一个问题是它不考虑闰秒，但我现在可以忍受这一点。

我的问题是，我还希望以这种格式存储出生日期。 现在我可以将01-01-1900作为开始日期并将该日期以来的天数存储在int中。 虽然我很确定这会很好用，但感觉epoch是一个完善的概念，但生日的感觉就像我正在构建我自己的约定，这是我通常想要避免的。

有没有建立标准将日期存储标准化为一个数字？ 哪个日期应该是基线日期？

Answer 1

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

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

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

1. 字母数字排序顺序是按时间顺序排列的，因此使用>，<，> =，<=和BETWEEN的查询子句可以完美地运行，假设您有一个适当精度的范围索引（-1表示完全精度）;
2. 它们是人类可读的，所以如果你正在浏览表格，那么数据是有意义的;
3. 此格式允许指定较低粒度的日期/时间。 例如，您应该将“2015-03”表示行军月份，或“2015-03-24”表示2015年3月24日。然后您可以使用此filter发出查询“startedOn> = 2015-03- 24 AND startedOn <2015-03-25“查找2015年3月24日开始的所有内容。即使startOn存储为完整的ISO-8601字符串，如”2015-03-24T12：34：56.789Z“，字符串比较的本质。

我在这里写过这个方法。

Answer 2

Teo的答案是正确的，除了我怀疑“完善”，数十亿的Microsoft Excel，LibreOffice和Lotus 1-2-3电子表格与他们自己的时代可能远远超过Unix时间使用。 或者十亿的Apple Cocoa设备和电脑都有自己的时代。

请注意，各种计算机环境已经使用了几十个不同的时代 。 Unix时间远非孤立甚至占主导地位。

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

如果可能，请使用日期时间精明数据类型。 一定要学习文档和实验，以清楚地了解它的行为。

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

在我所知的每个日期时间跟踪系统中，忽略闰秒。 他们的目的是使我们的每小时时钟与日历一起使用，因此出于商业目的， 闰秒在某种意义上意味着被忽略。

日期工作是令人惊讶的棘手和滑的业务。 搜索StackOverflow以发现许多问题。 尽量避免滚动自己的解决方案。 特别是对于C＃，请查看Noda Time库 。

Answer 3

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

我会问为什么冒险使用你自己的约定？ 这是一个风险，因为：如果有一段时间你想要增加你的日数，可能会根据他们出生那天的确切时间来订购人。 问题可以扩展到：如果在某些时候你想要测量更通用或更细粒度的时刻会怎么样; 您必须将整个function（可能在应用程序的多个层中）转换为更通用的机制/约定。 另一个（类似的）问题是：您是否总是为数据库中的人员测量一次一生的事件，还是能够创建新的无限制事件？ 随着事件数量的增加，碰撞风险也会增加，并且日计数不如以秒或毫秒为单位测量的时间戳。

UNIX时间基本上无处不在，您可以使用特殊方法在大多数编程语言中获取它。 我将始终在我的项目中支持和实施的计时架构是： http ： //www.currentmillis.com/tutorials/system-currentTimeMillis.html

正如我在上面链接的问题的答案中所述，自UNIX时代以来存储时间为毫秒的优点是：

• 架构清晰度：服务器端使用UTC，客户端通过其本地时区显示时间
• 数据库简单性：存储数字（毫秒）而不是像DateTimes这样的复杂数据结构
• 编程效率：在大多数编程语言中，你有日期/时间对象，从构造时的Epoch开始可以花费几毫秒（允许自动转换到客户端时区）

---

因为你提到了C＃，所以我想到了DateTime.MinValue 。 这基本上是0年（午夜，1月1日）。

此外，这将是一些代码，允许您从您选择的参考日期（无论它是什么）获得millis但请注意1900仍然不同于.NET的’epoch’（DateTime.MinValue）

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