I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is Ready.

The security considerations section of this document covers the security and privacy considerations I would have identified as possible areas of concern for a specification like this.

Section 7.3 in particular identifies the problem of inconsistent interpretation of timestamps by distinct entities (or, I'd add, even by the same entity across time). It's important for security-minded reviewers to understand that this problem is not created by the extension mechanism, as timezones have been altered in mundane ways (such as by moving the dates for daylight saving time) for decades. Agreement on the actual moment referenced by a timestamp has been and will continue to be a problem that in some cases unavoidably requires update of out-of-band metadata.

What this specification offers implementors is an additional degree of freedom in formulating timestamps with properties well-suited to the application at hand. Where a security protocol might want to stick to fixed offsets from UTC to minimize uncertainty (say, about credential expiration), a calendar protocol might want to make sure a meeting in Rome scheduled at noon on March 15, 2025 stays at that local time even if daylight saving time rules change in the period before the meeting actually happens. Additionally, if redundant offset information is included, this could enable applications to detect inconsistencies potentially indicative of out-of-date timezone definitions.