在URL

Question

在的OData/REST服务发送日期和时间与时区参数接受的方式我想允许标志着数据的日期范围的日期参数startDate和endDate返回。 例子：

GET /events?startDate=XXX&endDate=YYY 

问题：

1. 什么是标准格式的日期和时间，网址是什么？
2. 我应该考虑添加时区（或UTC偏移量）吗？如果未添加时区，会有什么预期？

Answer 1

见World Wide Web Consortium (W3C)日期格式，您可以在格式YYYY-MM-DDTHH派：MM：ss.sTZD

如1997-07-16T19：20：30.45 + 01：00

没有秒：

YYYY-MM-DDTHH：mmTZD（例如1997-07-16T19：20 + 01：00）

默认时区是美国东部标准时间：

1994-11-05T08：15：30-05：00对应于1994年11月5日，8 ：美国东部标准时间上午15：30, 。

1994-11-05T13：15：30Z对应于同一时刻。

Answer 2

W3C date format链接在@user7294900's answer是一个不错的选择。您只需要注意:和+这些字符 - 建议您使用URL-encode这些字符：在这种情况下，像2017-08-07T12:09:23.555+01:00这样的日期在URL中会变成2017-08-07T12%3A09%3A23.555%2B01%3A00。

您还可以使用ISO 8601 formats，它允许在不-和:分隔的格式，所以像2017-08-07T12:09:23.555+01:00的日期也可以写为：20170807T120923.555+0100（您仍然有字符进行URL编码，但是这可以变得更可读比第一种办法：20170807T120923.555%2B0100）

实际上W3C日期格式是配置文件（或ISO 8601的子集），因此两者都是不错的选择，因为大多数现代语言和系统具有ISO格式的支持。

我该如何/应该考虑添加时区（或UTC偏移量）？

首先，时区和偏移是不一样的东西（虽然他们彼此相关）。

偏移量与UTC的差值：+02:00表示“比UTC早2小时”，而-02:00表示“UTC后面2小时”。

时区是一个集所有不同的偏移，一个区域有，有其历史的过程中都会有，包括当发生这些变化的确切日期和时间。

如果我只是有一个像2017-08-07T12:09:23.555+01:00这样的日期，那么偏移量+01:00只是表明它比UTC早1小时，但它没有说明它在哪个时区。它可以是伦敦期间Daylight Saving Time（夏令时或夏令时），也可以是安道尔在冬季或其他许多地方。

Java使用IANA timezones names（总是格式为Region/City，如America/New_York或Europe/Berlin）。 避免使用三字母缩写（如EST或），因为它们ambiguous and not standard。

如果您的应用程序将处理日期和时间，在不同的区域，我建议使用UTC内部工作（所以日期会像2017-08-07T12:09:23.555Z - 在Z意味着“零偏差”，这反过来又is the same as "UTC"）。因此，您的后端代码始终与UTC协同工作，并在需要时将其更改为另一个时区（例如向用户显示时）。

如果你不需要用不同的时区工作，或者并不需要知道事件的确切时刻，你可以用一个“本地日期”工作（无时区，也没有偏移）。这取决于你的要求。

如果不添加时区有什么预期？

如果您使用本地日期/时间（不带时区/偏移量），则可能会出现“奇怪”或意外的结果，具体取决于代码处理日期的方式。

假设我有日期/时间2017-08-07T22:00（8月7日^2017年，下午10点）。它不具有任何时区信息，因此你必须假定在世界的哪个区域这个日期是：你可以假设它在你的时区，或在任何时区系统使用，但如果你开始涉及其他这些计算将失败时区。

例如：如果我认为这个日期是在伦敦，这将是等同于晚上9点在UTC。但如果当地日期在洛杉矶，则相当于UTC的2017-08-08T05:00（洛杉矶的晚上10点等于UTC的第二天凌晨5点）。此日期/时间将根据所使用的时区表示不同的时间。

所以，如果不使用偏移，你可能有这些结果，当然这取决于你的代码与日期做。如果你把它当作当地的日期和时间来处理，那应该没有问题。如果您在考虑UTC和/或不同时区进行计算，可能会出现问题。