Calendar-First Daily Reports: Handling Per-User Timezones in US/EU SaaS

Short answer: run one coarse UTC scheduler, then decide eligibility in application code using each user's IANA timezone and local date. Do not create a cron rule for every customer. For a daily report email, the scheduler should wake the system; it should not decide what “today” means. The useful boundary is simple: a UTC tick selects due users, a database claim makes the user-date event unique, and a worker sends the report from a durable queue. That design also fits a renewal reminder that must wait until a business deadline. The deadline is a calendar rule. Delivery is an execution detail. The clock is not the calendar. Should a daily report email use UTC cron or each user's timezone in a SaaS? Store the user's IANA timezone, preferred local send time, and the business date the report represents. A record such as Europe/Berlin carries daylight-saving rules; a stored UTC+1 offset does not. The same local 09:00 can map to different UTC instants during the year, and a