iCalendar P1D versus PT24H: why a day can end at a different hour
An event lasting one calendar day is not always an event lasting exactly 24 hours. When a time zone changes its clock, DURATION:P1D and DURATION:PT24H can lead to different local ending hours.
Illustrative noon-to-noon calculation with assumed offset changes
| Clock behavior overnight | P1D result | PT24H result |
|---|---|---|
| UTC+01:00→UTC+02:00 | Day 2 at 12:00 local; 23 elapsed hours | Day 2 at 13:00 local; 24 elapsed hours |
| UTC+02:00→UTC+01:00 | Day 2 at 12:00 local; 25 elapsed hours | Day 2 at 11:00 local; 24 elapsed hours |
| No relevant offset change | Next local day at 12:00; 24 hours | Next local day at 12:00; 24 hours |
Choose the duration that matches the real commitment
RFC 5545 section 3.3.6 distinguishes nominal durations expressed in weeks or days from accurate durations expressed in hours, minutes and seconds. A day’s exact elapsed length depends on its calendar position, including a daylight-saving transition. The specification adds larger components first when evaluating a mixed duration.
Use a nominal day when the intended end follows the local calendar-day position. Use an exact hour interval when the agreement really means that elapsed time. A timed appointment’s duration is different again from an all-day DATE label; do not change an event to all-day merely to hide a one-hour discrepancy.
Calculate a forward clock change
Use a fictional zone that advances from UTC+01:00 to UTC+02:00 during the night between Day 1 and Day 2. Start at 12:00 on Day 1, which is 11:00Z. Adding one nominal day reaches 12:00 on Day 2, now 10:00Z: 23 elapsed hours later.
Adding PT24H instead reaches 11:00Z on Day 2, which is 13:00 in the new offset. Both calculations are internally consistent; they answer different questions. These are explicit assumed offsets, not current rules for a named city or an observed app result.
Check a backward change too
Now assume a fictional zone changes from UTC+02:00 to UTC+01:00 during that night. Starting at 12:00 on Day 1 means 10:00Z. One nominal day reaches 12:00 on Day 2, or 11:00Z: 25 elapsed hours. Exactly 24 hours reaches 10:00Z on Day 2, or 11:00 local.
The difference is caused by the specified clock transition, not a rule that every P1D lasts 23 or 25 hours. On an ordinary day without a relevant offset change, the two examples can coincide. Real named-zone data and the exact start date are needed for a real calculation.
Keep an explicit end separate from a duration
For a VEVENT, the RFC permits DURATION as an alternative to DTEND and prohibits specifying both in the same event. An explicit DTEND supplies the ending value; DURATION describes how to obtain the end from the start. DATE-based starts have additional restrictions: their duration uses day or week form.
This guide does not claim that Cloud Calendars offers raw DURATION syntax or chooses one representation for every provider. Inspect the original event and the supported provider editor. For an important overnight commitment, confirm the intended local endpoint and elapsed interval before making a correction.
What it looks like
Cloud Calendars overview, using our product images. Provider settings and protocol examples described in this guide are separate from the screens shown here.
What to do
- Write the intended local ending time and whether elapsed hours are contractual.
- Check the actual named zone and transition date.
- Inspect whether the record uses DURATION or DTEND.
- Compare both endpoints in the owning provider before shifting the event.
Questions
- Does P1D always mean 86400 seconds?
- No. The RFC treats days as nominal durations whose exact length depends on calendar position and relevant clock changes.
- May a VEVENT contain both DTEND and DURATION?
- No. They are alternative ways of specifying its end under RFC 5545.