Holiday dates move across calendar systems

What it is

A calendar-dependent holiday date is determined by a solar, lunar, or lunisolar calendar, a weekday-relative rule, or observation, so it cannot be attached permanently to one Gregorian month and day. Calendar conversion maps the same holiday to different Gregorian dates across years. Some observances use sunset or another instant as the day boundary, and some await an announcement by a local authority based on actual observation. A product needs the rule, jurisdiction, calendar, and certainty—not merely one year's Gregorian result.

Why it happens

Calendars define years, months, intercalation, and day boundaries differently. A holiday fixed to a month and day in one calendar moves when converted to Gregorian dates; rules such as “the nth weekday of a month” also produce a new date each year. An algorithmic calendar can be computed when its rule and version are known, whereas an observational calendar may depend on location, observation criteria, and a deciding authority, so an estimate and the declared date can diverge. Storing only an annually repeating Gregorian month-day makes reminders drift; storing only display text prevents dependable sorting, conversion, and uncertainty handling.

Studying it

For every target holiday, record the local name, population and jurisdiction, source-calendar rule, day boundary, issuing authority, announcement state, conversion library, and version. Back-test against dates published by the authority, separating calendar calculation, time-zone projection, and localized rendering. For observational holidays, measure divergence between predicted and final dates, announcement lead time, and downstream update latency. User studies can compare Gregorian-only, dual-calendar, and estimated/pending labels for comprehension, planning, and trust. Do not infer a person's observance from a regional label alone.

Where it stops holding

A converter maps a supplied rule; it cannot decide which rule a religion, state, locality, or community recognizes. Different authorities may declare different dates in the same year. An observance crossing sunset or midnight is not a timezone-free all-day date. Calendar reforms and local historical practice can make a modern proleptic calculation a poor account of what people actually observed. Future observation-dependent dates should remain estimates that an authoritative announcement can override, not be presented as algorithmically settled.

Applying it

• Model a holiday as a rule plus yearly instances. Store calendar, source-calendar date or relative rule, jurisdiction/community, day boundary, IANA time zone, provenance, status, and rule version; treat the Gregorian date as a recomputable projection.
• Use the familiar local name and date. For cross-calendar coordination, show source-calendar and Gregorian dates together and label the instance as estimated, pending confirmation, or announced.
• Create an announcement-update workflow for observational dates with a named source and owner. On change, recompute reminders, staffing, and content plans, and tell affected users what moved.
• Test leap years, intercalary months, sunset boundaries, cross-zone viewing, and conflicting authority results. Pin the conversion-library version and regress against published historical dates rather than trusting one online converter as ground truth.

Related

• Same group: S3.03.1 Workdays and rest days vary by region · S3.03.3 Marketing occasions cannot be copied unchanged across markets · S3.03.4 Daylight-saving observance and transition dates are not uniform
• Adjacent: S2.01.2 Numeric-only dates are ambiguous · S2.01.5 Coexisting non-Gregorian calendar display
• Search terms: movable holiday · calendar conversion · observational calendar