我有一个node.js应用程序，它在数据库中存储了许多日期。它们以ISO格式存储，例如'2016-11-02T16:30:12-04:00'。
某些字段是日期，日期只是日期，其他字段是日期/时间。日期/时间的一个例子是＆＃34;最后一次修改＆＃34;记录，一个人的生日只是一个约会。
问题是关于这些事情的存储和查询模式的最佳实践。由于日期总是有时间，因此您必须选择如何存储例如生日。 Following the 5 laws of API dates and times这当然是在UTC中完成的。
虽然适当的API行为似乎不清楚但存在边缘情况。假设有人将生日提交给'2016-11-02T16:30:12-04:00'的API。这是个坏消息，因为像/users?birthdate=2016-11-02这样的搜索会失败，因为该日期将转换为'2016-11-02T00:00:00Z'并且无法在数据库中匹配。那么应该纠正什么行为？
POST是用户，请将日期字段转换为UTC午夜的日期，然后让查询生日的约定应该相同吗？2016-11-02是否真的在寻找2016-11-02T00:00:00Z <= x <= 2016-11-02:23:59:59Z？'2016-11-02T16:30:12-04:00'的生日真的意味着美国东部时间下午4:30，并不仅仅意味着11月2日？这里用于区分日期和日期时间的既定模式/最佳实践是什么？
答案 0 :(得分：1)
我一直在研究REST最佳实践和标准很长一段时间，我不记得读过任何有关它的内容，但是对于ISO标准的使用。从您的描述看，它似乎真的取决于应用程序及其用例。
我会选择＃2选项：如果GET请求带有日期但没有时间，请将其视为一整天的查询，并在GET响应服务器代码中执行“转换”。如果准确时间可能偶尔重要，您可能希望同时支持“日期”和单独的“时间”查询字符串参数。这也可以帮助您让客户“不知道”您选择的数据库存储格式，甚至可以允许您支持本地化的日期格式。
答案 1 :(得分：1)
这里的问题是UTC的使用，这意味着有一段时间与之相关。没有，生日被认为（在iCalendar中）是“浮动日期”，并且没有与之相关的特定时间。
如果您的出生日期是11月3日，并且您移居澳大利亚，您的出生日期实际上并没有变为11月2日，因为您的出生日期没有时间，没有时区，并且无论您身在何处世界。
解决方案很简单。如果您允许用户提交生日搜索的日期/时间，那么您应该“切断”时间和时区。假设您只是使用日期部分，只是根据它搜索您的数据库。
理想情况下，您根本不允许用户提交时间。我认为这只会造成混乱。只需强制api客户提交日期。
这些“5条法则”极端过分简化，并不适用于很多情况。