在OData / REST服务中，我想允许日期参数startDate和endDate，它们标记返回的数据的日期范围。
例：
GET /events?startDate=XXX&endDate=YYY
问题：
URL中日期和时间的标准格式是什么？
我应该考虑添加时区(或UTC偏移)吗？ 如果没有添加时区，会有什么期望？
如果有帮助，你能否回答我的答案？
在@ user7294900的答案中链接的W3C日期格式是一个不错的选择。您只需要注意字符:和+ - 建议对这些字符进行URL编码：在这种情况下，像2017-08-07T12:09:23.555+01:00这样的日期将在URL中变为2017-08-07T12%3A09%3A23.555%2B01%3A00。
您还可以使用ISO 8601格式，它允许不带-和:分隔符的格式，因此像2017-08-07T12:09:23.555+01:00这样的日期也可以写为20170807T120923.555+0100(您仍然可以使用URL编码的字符，但这比第一个选项更具可读性：20170807T120923.555%2B0100)
实际上，W3C日期格式是ISO 8601的配置文件(或子集)，因此两者都是不错的选择，因为大多数现代语言和系统都支持ISO格式。
How/Should I consider adding timezone (or UTC offset)?
首先，时区和偏移量不是一回事(尽管它们彼此相关)。
偏移量与UTC的差异：+02:00表示"比UTC早2小时"，-02:00表示"比UTC晚2小时"。
时区是一个区域在其历史中具有，已经和将要具有的所有不同偏移的集合，包括这些变化发生的确切日期和时间。
如果我只有一个像2017-08-07T12:09:23.555+01:00的日期，偏移量+01:00只表示它比UTC提前1小时，但它没有说明它在哪个时区。它可以是夏令时(夏令时或夏令时)，也可以是冬季安道尔或其他许多人。
Java使用IANA时区名称(始终采用Region/City格式，如America/New_York或Europe/Berlin)。
避免使用3个字母的缩写(如EST或PST)，因为它们不明确且不标准。
如果您的应用程序将处理不同区域的日期和时间，我建议使用UTC内部工作(因此日期将类似于2017-08-07T12:09:23.555Z - Z表示"零偏移"，这反过来与"UTC"相同)。因此，您的后端代码始终与UTC一起使用，只需在需要时将其更改为另一个时区(例如向用户显示时)。
如果您不需要使用不同的时区，或者不需要知道事件的确切时刻，则可以使用"本地日期"(没有时区也不偏移)。这取决于您的要求。
What is expected if timezone was not added?
如果使用本地日期/时间(没有时区/偏移量)，则可能会出现"奇怪"或意外结果，具体取决于代码处理日期的方式。
假设我有日期/时间2017-08-07T22:00(2017年8月7日晚上10点)。它没有任何时区信息，因此您必须假设这个日期在世界的哪个区域：您可以假设它在您的时区或系统正在使用的任何时区，但如果您开始涉及另一个时间，这些计算将失败时区。
示例：如果我认为此日期在伦敦，它将相当于UTC的晚上9点。但如果本地日期在洛杉矶，它将相当于UTC中的2017-08-08T05:00(洛杉矶晚上10点等于第二天凌晨5点在UTC)。根据使用的时区，此日期/时间将代表不同的瞬间。
因此，如果未使用偏移量，您可能会得到这些结果，但这当然取决于您的代码对日期的处理方式。如果你把它当作当地的日期和时间，那应该没有问题。如果您正在考虑UTC和/或不同的时区进行计算，则可能存在问题。
请参阅万维网联盟(W3C)日期格式，您可以采用YYYY-MM-DDThh格式发送：mm：ss.sTZD
e.g 1997-07-16T19:20:30.45+01:00
没有秒：
YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
默认时区是美国东部标准时间：
1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am,
US Eastern Standard Time.
1994-11-05T13:15:30Z corresponds to the same instant.
有没有秒的标准格式？
相同链接：YYYY-MM-DDThh：mmTZD(例如1997-07-16T19：20 + 01:00)
谢谢！
你能评论为什么贬低？
我没有贬低它！ 我赞成它。
785
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
