【问题标题】:Recommended date format for REST APIREST API 的推荐日期格式
【发布时间】:2011-04-03 06:35:44
【问题描述】:

我正在编写一个公开 REST API 的应用程序。一些查询参数将是日期/时间(精确到秒),一些响应将是时间戳(精确到毫秒)。

服务器上的 API 实现是用 Java 编写的。客户端应用程序可以是任何东西 - java、javascript、.NET。 API 返回 XML 或 JSON 数据。日期/时间数据存储在 Oracle 数据库中。

有没有人根据之前的痛苦建议传递这些日期/时间值的最佳格式格式是什么。我想自己只使用一个老式的 long 来存储自 1970 年 1 月 1 日 00:00:00 GMT 以来的毫秒数。

编辑 API 中涵盖的日期范围是针对实时事件的,因此在 2010 年之前不会有任何内容,在 2038 年之后(此处设置为滥用)将不会有任何内容。

我猜最好由

决定

a) 多种语言支持将此 long 转换为内部日期对象,而无需编写代码。

b) 最低的 CPU 开销(在服务器应用上)

【问题讨论】:

    标签: java javascript datetime timestamp date-formatting


    【解决方案1】:

    ISO 8601 一路

    使用任何基于纪元的方法意味着您被绑定到有符号 32 位 INT 的范围(在大多数系统中)(1901-12-13T20:45:52+00:00 到 2038-01-19T03:14 :07+00:00) 这实际上更像是一个 时间戳 而不是日期,因为它无法处理影响深远的历史或未来日期。

    【讨论】:

    • 嗨彼得 - 我已经编辑了问题以澄清我将要查询的日期范围,在“时代范围”内很舒服 - 这会改变你对 ISO 8601 的建议吗?
    • @Tom 我知道,我在等它
    • @Kevin 是的,因为 Date 构造函数可以很好地理解 ISO 8601 日期。您可能希望按照 Darin 的回答中建议的特殊方式划分日期,但我仍然坚信我们应该坚持 ISO 8601。作为额外的奖励,它比时间戳值更易于人类阅读。而且,FWIW,Facebook 的 Graph API(全是 JSON)使用 ISO 8601。
    • @PeterBailey - 此链接 -agiletribe.wordpress.com/2015/06/10/jsonrest-api-handling-dates 建议使用整数 epoch 以避免 iso-8601 格式可能遇到的人类可读性问题.如果您有不同的看法,请告诉我
    猜你喜欢
    • 2012-03-23
    • 2020-01-22
    • 2015-06-22
    • 2012-01-06
    • 2021-12-12
    • 2019-03-24
    • 1970-01-01
    • 2013-08-25
    • 1970-01-01
    相关资源
    最近更新 更多