RFC 5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Note: This RFC has been updated by RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253

Errata ID: 5082
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: George Sexton
Date Reported: 2017-08-10
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.8.7.3 says:

N/A

It should say:

The value must not be in the future.

Notes:

If future values are allowed for LAST-MODIFIED, it makes it very difficult for software to perform change management for a VEVENT.

Say for example, an event is imported from a source and the VEVENT has a future date. For example, December 20 2017 12:00:00Z

That event is then edited and assigned the actual correct date and time. Say August 9 2017 13:45:44Z.

Software that examines the VEVENT's LAST-MODIFIED to determine if the VEVENT record has been modified will not see the VEVENT is updated.

In order for different systems to perform change management, the value for LAST-MODIFIED should NEVER be a future date.
--VERIFIER NOTES--
The description of the property already implies that it is not in the future. And any handling of clock skew is an iTIP/CalDAV protocol issue, NOT a data format issue.

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Report New Errata