Applies to: Annual schedules, copied calendar examples or reminders containing 29 February.
The useful distinctions
- Gregorian calendar dates depend on the year.
- 29 February 2028 is valid; 29 February 2029 is not.
- A timezone conversion cannot supply a missing or invalid source occurrence.
Validate the calendar before the clock
When an event uses 29 February, the year is part of its identity. A copied announcement that omits the year leaves a real planning gap. A timezone calculation can move a valid instant across midnight, but it cannot decide what an organiser intended when the starting calendar date does not exist. Treat that as a source question. Do not quietly substitute the last day of February or the first day of March.
Clarify recurrence rules explicitly
An annual label is not a complete instruction for a leap-day occurrence. The organiser might skip some years, move the event or publish individual dates. Those are different policies, and the viewer should not choose one on the organiser’s behalf. Keep a confirmed exception attached to the recurring reminder so the same ambiguity does not return later. If no exception is supplied, leave the future occurrence unresolved rather than inventing a plausible date.
Hypothetical worked example
An invented series called Calendar Workshop lists its next session as 29 February 2029 at 20:00 UTC. Gregorian date validation rejects that day, while 29 February 2028 is valid. The viewer asks whether the series means 28 February 2029, 1 March 2029 or no session that year. Only after the organiser supplies a valid occurrence should the viewer calculate a local start time and create a reminder.
A focused way to proceed
- Read the complete year-month-day value.
- Validate that calendar date before converting the time.
- Ask the source how a recurring event handles years without the date.
When to stop or ask for help
Return the invalid date to the source and request a corrected dated occurrence or explicit recurrence policy.