在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)
谢谢!
你能评论为什么贬低?
我没有贬低它! 我赞成它。