Confirmed public review
An impossible date in the Microsoft Azure REST API Guidelines
A deprecation-header example uses 2009-27-07, which cannot be a calendar date in the YYYY-MM-DD order the document itself requires.
- Candidates reviewed
- 5
- Confirmed findings
- 1
- Held for context
- 4
Review summary
What the evidence supports
We reviewed five candidate records against the cited source revision. One candidate was confirmed as a publishable finding. Four were held because they duplicated the same passage rather than identifying independent defects.
The confirmed issue is narrow and directly supported by the document. The guidelines say deprecation dates should follow ISO 8601 and illustrate a YYYY-MM-DD value, while one API-version example contains 27 in the month position.
The example contains an impossible calendar date
The example gives the API version as 2009-27-07. In the YYYY-MM-DD order used by the surrounding guidance, 27 occupies the month position and is not a valid month.
Relevant passage
`azure-deprecating: API version 2009-27-07 will retire on 2022-12-01 (https://azure.microsoft.com/updates/video-analyzer-retirement)`
Why this is confirmed
The same section states that the relevant date should follow ISO 8601 and gives 2022-10-31 as its format example. The later deprecation-header example uses 2009-27-07. That value cannot represent a valid calendar date in the stated order, so the example is internally inconsistent with the guidance beside it.
Practical correction
Replace 2009-27-07 with the intended valid API-version date after checking the authoritative version record, then keep the example in the documented YYYY-MM-DD order.
The cited source establishes that the published value is impossible, but it does not establish which valid date was intended. This review therefore does not assert an exact replacement.
Editorial accounting
What we did not count
The review workflow surfaced the same invalid-date passage four additional times. Those candidate records did not point to four independent passages or defects, so they were held as duplicates and are not counted as confirmed findings.
Source and attribution
Read the original revision
Microsoft, “Microsoft Azure REST API Guidelines,” revision a7022a299442a8352431874e63ec4dff548a1b81, licensed under CC BY 4.0. Lunes Studio excerpted the passage and added independent editorial commentary. Microsoft does not sponsor or endorse this review.
This work is licensed under the Creative Commons Attribution 4.0 International License.