Consider adding "CUI" date format to the API as an additional response parameter #199
Labels
design-decision
An issue that documents a past, present or future design decision in the project
feature-request
New feature or request
nice-to-have
A feature which would be nice to have but is not essential
not-mvp
In discussions with some implementers it has become clear that some wish to use "NHS Common User Interface" style dates:
YYYY-MMM-DD
(whereMMM
is a three-letter Month name, not a number, for example 'AUG'). The advantages of this are said to be that it is virtually impossible to misinterpret the Month for Day of Month. Compare with other common date formats such as DD/MM/YYYY within which it's quite easy to get confused with MM/DD/YYYY (American date format). In this regard it could be said that the CUI date format is 'human-friendly'Currently we use ISO8601 date format which has the advantage of being very 'computer-friendly' in that it is trivial using standard date libraries to convert to and from ISO8601 dates. Whereas converting to and from CUI dates may be harder and potentially less easy to validate in both directions.
I stressed to all stakeholders that although this could be implemented in the API, the actual place the implementation needs to be done is in the implementer's client application. So although we can and will consider adding this feature as a 'convenience' to the API response, it is NOT the whole story and I was very careful to request that we have a proper technical discussion with implementer-side developers to ensure that we are not being asked to chase a spurious 'NHS DTAC Project Manager Jobsworth Requirement' which they have not fully understood but intend to fully demand.
The text was updated successfully, but these errors were encountered: