在OData / REST服务中，我想允许日期参数startDate和endDate标记返回数据的日期范围。
示例：
GET /events?startDate=XXX&endDate=YYY
问题：
答案 0 :(得分：7)
W3C date format中链接的@user7294900's answer是个不错的选择。您只需要关注字符:和+ - 建议URL-encode这些字符：在这种情况下，2017-08-07T12:09:23.555+01:00之类的日期会变成2017-08-07T12%3A09%3A23.555%2B01%3A00网址中的-。
您还可以使用ISO 8601 formats，它允许使用不包含:和2017-08-07T12:09:23.555+01:00分隔符的格式，因此20170807T120923.555+0100之类的日期也可以写为20170807T120923.555%2B0100 （你仍然有URL编码的字符，但这比第一个选项更具可读性：+02:00）
实际上，W3C日期格式是ISO 8601的配置文件（或子集），因此两者都是不错的选择，因为大多数现代语言和系统都支持ISO格式。
如何/我应该考虑添加时区（或UTC偏移）？
首先，时区和偏移不是一回事（尽管它们彼此相关）。
偏移是与UTC的差异：-02:00表示＆＃34;比UTC早2小时＆＃34;并且2017-08-07T12:09:23.555+01:00表示＆＃34;比UTC＆＃34;落后2小时。
时区是一个区域在历史记录中拥有，拥有和将要拥有的所有不同偏移的集合，包括发生这些变化的确切日期和时间。
如果我只有+01:00之类的日期，则偏移量Region/City只表示它比UTC提前1小时，但它并没有说出它在哪个时区。在Daylight Saving Time（夏令时或夏令时）期间可以是伦敦，也可以是冬季安道尔或其他许多人。
Java使用IANA timezones names（始终采用America/New_York格式，如Europe/Berlin或EST。
避免使用3个字母的缩写（例如PST或2017-08-07T12:09:23.555Z），因为它们是ambiguous and not standard。
如果您的应用程序将处理不同区域的日期和时间，我建议使用UTC内部工作（因此日期将类似于Z - 2017-08-07T22:00表示＆＃34;零偏移＆＃34 ;，反过来is the same as "UTC"）。因此，您的后端代码始终与UTC一起使用，并在需要时将其更改为另一个时区（例如在向用户显示时）。
如果您不需要使用不同的时区，或者不需要知道事件的确切时刻，您可以使用＆＃34;本地日期＆＃34; （没有时区也没有抵消）。它取决于您的要求。
如果没有添加时区，会有什么期待？
如果您使用本地日期/时间（没有时区/偏移量），您可以拥有＆＃34;奇怪的＆＃34;或意外结果，具体取决于您的代码处理日期的方式。
假设我有日期/时间2017-08-08T05:00（2017年8月7日 th ，晚上10点）。它没有任何时区信息，因此您必须假设这个日期在世界的哪个区域：您可以假设它在您的时区，或系统正在使用的任何时区，但这些计算将如果你开始涉及另一个时区，那就失败了。
示例：如果我认为此日期在伦敦，它将相当于UTC的晚上9点。但如果本地日期在洛杉矶，它将相当于UTC中的.WillCascadeOnDelete(false)（洛杉矶晚上10点等于第二天凌晨5点，UTC）。根据使用的时区，此日期/时间将代表不同的时刻。
因此，如果未使用偏移量，您可能会得到这些结果，但这当然取决于您的代码对日期的处理方式。如果您将其视为当地日期和时间，则应该没有问题。如果您正在考虑UTC和/或不同的时区进行计算，则可能存在问题。
答案 1 :(得分：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对应同一时刻。