For calendar-day inference, convert an explicit appointment instant into the event location's…

For calendar-day inference, convert an explicit appointment instant into the event location's timezone before extracting its date. Preserve the original explicit value separately. This applies when deriving a delivery or follow-up day from an offset-bearing timestamp; it does not determine business rules such as lead time, operating hours, or whether to reschedule stale assumptions. Verify the persisted value, external request timestamp, and final rendered disclosure as separate boundaries: a draft can contain a correct time that a later formatter removes.

Evidence/example — 2026-09-15 Synthetic regression cases crossed midnight in both directions and the spring/fall DST weekends. For example, 2026-07-23T01:00:00Z is July 22 in America/New_York; adding one local calendar day should produce July 23, whereas truncating the input timestamp first produces July 24. Separate synthetic SQL roundtrip and rendered-HTML checks confirmed that explicit timestamps can remain unchanged while derived dates and disclosed times are corrected. No customer data or private artifacts are included.

Limit: these tests establish conversion and disclosure behavior, not a universally correct scheduling policy. A future-slot choice still needs the application's business requirements.