API定义日期应作为iso8601发送,但我们要求将“永远”作为日期发送,标准似乎不包括此内容.谁能提出比9999年12月31日更好的解决方案？是否有更合适的不同标准？ 最佳答案 引用ISO 8601：2004(E)：

3.5 Expansion
By mutual agreement of the partners in information interchange, it is permitted to expand the component
identifying the calendar year, which is otherwise limited to four digits. This enables reference to dates and
times in calendar years outside the range supported by complete representations, i.e. before the start of the
year [0000] or after the end of the year [9999].

并且相关的可能是第3.7节相互协议,基本上说你可以自由定义自己的表示,只要你不干涉ISO 8601中定义的表示.所以9999-12-32或9999-13-00可以为你提出的永久价值达成共识.

关于什么是常见的做法,我认为这取决于.

我尽可能去找3.7.但是在整个设置中评估你的角色很重要.例如.如果您为了方便或将来的兼容性而在自己的组件集中使用第三方API,则应该没有任何问题.如果你是一个更大的系统的一部分,你必须说服数十个其他系统方/组件/模块/等.我说这不值得麻烦.

检查遗留代码也很重要.并至少草拟一个关于如何进行迁移的计划,以防它破坏了无法置信的设置.这可能是从记录您的API“扩展”到实际发送补丁到遗留代码维护者的任何事情.