The API defines that a date should be sent as ISO 8601, but we need to send "forever" as a date, and the standard does not seem to cover it. Can anyone recommend a better solution than 31 December 99 99? Is there a different standard that would be more appropriate?
citing ISO 8601: 2004 (e):
With the mutual agreement of partners in the 3.5 Extension information interchange, the component identifying that calendar year is permitted to extend, which is otherwise limited to four digits. It refers to the context of the date and time in calendar years outside the category supported by the full representation, i.e. the beginning of the year [0000] or the end of the year [99 99]
And the relevant section may also be 3.7 mutual agreement which basically says that unless you interfere with the representations defined in ISO 8601, Are free to define the representations. 99 99-12-32 or 99 99 -13 -00 may agree with each other for your proposed code.
According to common things, I would say that it depends. > Whenever possible I had to go for 3.7. But it is important to assess your role within the entire set-up. If you are using a third party API within your own set components for convenience or future compatibility, then there should be no problem at all. If you are part of a larger system and you have to understand tens of other system parties / components / modules / etc. I can say that this is not worth the trouble.
Legacy code is also very important to check. And sketch about at least one plan in which how to migrate, if it breaks the set-up beyond belief, it may be anything from the documentation of your API "extension" that the legacy code maintenance actually Send patches.
Comments
Post a Comment