在 OData/REST 服务中，我希望允许日期参数
startDateendDateGET /events?startDate=XXX&endDate=YYY
问题：
@user7294900 的答案中链接的W3C 日期格式是一个不错的选择。您只需要注意字符
:+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） -encode，但这比第一个选项更具可读性：
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 小时，但它没有说明它在哪个时区。它可以是夏令时（DST，或夏令时）期间的伦敦，也可以是冬季的安道尔，或许多其他时间。 Java 使用
IANA 时区名称（始终采用 Region/City
格式，如
America/New_York或
Europe/Berlin）。 避免使用 3 个字母的缩写（如
EST或
PST），因为它们不明确且不标准。 如果您的应用程序将处理不同区域的日期和时间，我建议在内部使用 UTC（因此日期将类似于
2017-08-07T12:09:23.555Z
-
Z表示“零偏移”，而与“UTC 相同”） “）。因此，您的后端代码始终使用 UTC，只需在需要时将其更改为另一个时区（例如向用户显示时）。 如果您不需要使用不同的时区或不需要知道事件的确切时刻，您可以使用“本地日期”（没有时区或偏移量）。这取决于您的要求。
如果不添加时区会怎样？如果您使用本地日期/时间（没有时区/偏移），您可能会得到“奇怪”或意外的结果，具体取决于您的代码处理日期的方式。
假设我有日期/时间
2017-08-07T22:00
（2017 年 8 月 7 日，晚上 10 点）。它没有任何时区信息，因此您必须假设该日期位于世界的哪个地区：您可以假设它在您的时区，或者系统正在使用的任何时区，但如果您开始涉及另一个时区，这些计算将会失败时区。 示例：如果我认为该日期在伦敦，则相当于世界标准时间晚上 9 点。但如果本地日期位于洛杉矶，则相当于 UTC 中的
2017-08-08T05:00
（洛杉矶晚上 10 点等于 UTC 第二天凌晨 5 点）。该日期/时间将代表不同的时刻，具体取决于所使用的时区。因此，如果不使用偏移量，您可能会得到这些结果，但是当然，这取决于您的代码对日期的处理方式。如果您将其视为本地日期和时间，应该没有问题。如果您在考虑 UTC 和/或不同时区进行计算，可能会出现问题。
万维网联盟 (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 对应于同一时刻。