Question

An API defines that a date should be sent as iso8601, but we have a requirement to send “forever” as a date, and the standard does not seem to cover this. Can anyone suggest a better solution than Dec 31 9999? Is there a different standard that would be more appropriate?

Answer 1

Quoting 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].

And also relevant may be section 3.7 Mutual agreement which basically says you’re free to define your own representations as long as you don’t interfere with the representations defined in ISO 8601. So 9999-12-32 or 9999-13-00 could be mutually agreed upon for your proposed forever value.

As to what’s common practice, I’d say it depends.

I’d go for 3.7 whenever possible. But it’s important to assess your role within the whole set-up. E.g. if you’re using a 3rd party API within your own set of components for the sake of convenience or future compatibility, there should be no problem at all. If you’re part of a bigger system and you’d have to convince tens of other system parties/components/modules/etc. I’d say it’s not worth the trouble.

Also very important to check legacy code. And at least sketch out a plan on how to do the migration in case it breaks set-ups beyond belief. That could be anything from documenting your API “extension” to actually sending patches to the legacy code maintainers.