Date and time based discount banners

Definitely want this ASAP, super useful feature. Seems very doable for calendars that are on set dates, may be more tricky if not gregorian calendar. Heres a workaround claude 4.6 proposes: Here you go: Feedback: Full implementation roadmap + APIs + email integration for date/time discount banners Really excited about this feature. Here is a full breakdown covering how to build it globally, what existing tools might help, and how email with timed discount codes could work — all in one place. Take or leave any of this, just wanted to share what I found! Phase 1 — Core date/time engine (build this first) Keep it simple to start: Fixed date triggers (e.g. December 25) Floating date triggers (e.g. 4th Thursday of November for US Thanksgiving) Flash sale windows with auto-dismiss when the time expires Timezone-aware scheduling (fire in merchant's local timezone, not UTC) A manual % deal field per banner Priority rules for when two holidays overlap in the same region Gregorian calendar only. Single country. Manual entry. Get this solid before scaling. Phase 2 — Country and region grouping Rather than merchants selecting 193 countries one by one, grouping them by region could work nicely: Americas (35 countries) — Christmas, Thanksgiving, Día de Muertos Europe (44) — Christmas, Easter, national days East & SE Asia (22) — Lunar New Year, Golden Week, Chuseok South Asia (8) — Diwali, Eid, Holi Middle East (18) — Eid al-Fitr, Eid al-Adha, Ramadan Africa (54) — mix of Islamic, Christian, national holidays Oceania (14) — Christmas, ANZAC Day Central Asia (5) — Nowruz, Eid, national independence days Merchants toggle whole regions on/off, then add individual countries outside their home region if needed (e.g. a US merchant adding Japan for Lunar New Year). Phase 3 — Holiday importance tiers and deal % suggestions Not all holidays are equal. Suggesting defaults by tier might be a nice touch: Tier 1 — Major national (Christmas, Eid al-Fitr, Diwali, Lunar New Year, Black Friday): suggest 40–70% off Tier 2 — Widely observed (Valentine's Day, Mother's Day, Easter, Halloween): suggest 20–39% off Tier 3 — Regional/minor (national independence days, local harvest festivals): suggest 10–19% off Tier 4 — Awareness/cultural (Earth Day, Pride Month): suggest 5–9% off Tier assignment could be based on: official public holiday status, % of population observing, and historical e-commerce uplift data. Letting merchants manually bump any holiday one tier up or down would also help with edge cases. One thing worth thinking through early: who decides which tier a holiday belongs to, and how transparent is the methodology? "Why is my national holiday only Tier 3?" could become a support ticket. A public scoring rubric might save some of that friction down the line. Phase 4 — Non-Gregorian calendar support (the tricky part) This is where it gets technically interesting. Six additional calendar systems would eventually be needed: Islamic Hijri (lunar, shifts ~11 days/year) — Eid al-Fitr, Ramadan, Eid al-Adha — affects ~57 countries Chinese Lunar (lunisolar) — Lunar New Year, Mid-Autumn Festival — affects 15+ countries Hebrew (lunisolar) — Rosh Hashanah, Passover, Hanukkah Hindu/Vikram (lunisolar, regional variants) — Diwali, Holi, Navratri Ethiopian (solar, 13 months) — Timkat, Enkutatash Persian/Solar Hijri (solar, starts at vernal equinox) — Nowruz Some practical notes that might help: Pre-computing Gregorian equivalents 3 years ahead for floating holidays avoids last-minute gaps An annual recalculation job keeps next year's Islamic/lunar dates current For Eid specifically: Saudi Arabia and Indonesia can officially declare different dates based on local moon sighting — offering merchants a ±1 day banner window option might be the most practical workaround An established library for calendar conversion math (HijriCalendar.js, lunisolar, etc.) would save a lot of pain here Phase 5 — AI suggestions and personalization (future) Once the data foundation is solid, some nice things become possible: Matching merchant category to relevant holidays automatically (florist → Valentine's/Mother's Day, electronics → Black Friday) Suggesting deal % based on merchant category + holiday tier + platform conversion data Detecting visitor timezone/locale to show the right banner per visitor, not just per merchant location A full-year calendar preview so merchants can see all upcoming holidays across their active regions Some existing APIs worth knowing about before building holiday data from scratch Thought this might be useful — there are some solid options already out there: Free / open source: Nager.Date (github.com/nager/Nager.Date) — free, open source, MIT license, 100+ countries, clean REST API, no key needed. Can be self-hosted via Docker (docker run -p 80:8080 nager/nager-date), so zero cost and no rate limits. Returns holiday type, local name in native language, and subdivision codes for regional holidays. Free for commercial use. OpenHolidays API (openholidaysapi.org) — newer open-source project, fewer countries but higher accuracy for the ones it covers. Includes school holidays too. Paid but affordable: Calendarific — 230+ countries and regions, 100+ languages, public/bank/religious holidays. Free tier is 500 API calls/month (fine for building and testing). Probably the most comprehensive option for reaching all 193 countries. AbstractAPI Holidays — clean JSON, good developer experience, covers most major countries. On 193-country coverage honestly: No single free source covers all 193 UN member states with full religious and cultural holiday granularity. A practical two-layer approach might be: Nager.Date self-hosted as the primary source (free, covers ~100 countries well) Calendarific to fill the gaps — remaining countries and religious/cultural holidays Nager doesn't track A small internal override table for any country-specific corrections merchants flag This keeps costs near-zero at early scale while giving solid global coverage. Sub-national granularity is also possible — both Nager.Date and Calendarific return holidays at the regional level where relevant (different German states, Australian states, Indian states all have different sets). Nager calls these SubdivisionCodes. Something to consider exposing in the UI eventually, probably Phase 3 rather than Phase 1. Email integration idea: timed discount codes triggered by holidays This could be a really powerful future feature. Here is one way it might work: Holiday API says Eid al-Fitr is March 30 Merchant sets: "send 48 hours before, 30% off code, valid for 72 hours" Backend scheduler fires the email job on March 28 Email contains: discount code, % off, live countdown timer, start and end datetime Email sending options with generous free tiers (current as of 2026): Resend (resend.com) — 3,000 emails/month free permanently. Great developer experience, clean REST API, SMTP relay available, webhooks for tracking. Probably the easiest starting point. Brevo (formerly Sendinblue) — 300 emails/day free permanently (9,000/month), REST API + SMTP, marketing automation included. Good if you want marketing and transactional in one place. Amazon SES — $0.10 per 1,000 emails. Cheapest at scale, worth it past ~50,000 emails/month. Requires AWS setup. Worth noting: SendGrid removed their permanent free tier in May 2025, so probably worth avoiding for new projects. Example REST API payload to an email provider: json{ "to": "customer@example.com", "template": "holiday_discount", "variables": { "holiday_name": "Eid al-Fitr", "discount_code": "EID30", "discount_percent": 30, "valid_from": "2026-⁠03-⁠30T00:00:00Z", "valid_until": "2026-⁠04-⁠02T00:00:00Z", "timer_end_unix": 1743465600 } } For the countdown timer inside the email: services like Sendtric or Motion Mail generate an animated GIF timer from a URL parameter that works in any email client without JavaScript — <img src="https://sendtric.com/countdown/abc123?deadline=1743465600">. This is how most major e-commerce holiday email timers work under the hood. Simple scheduler flow: Holiday API → Scheduler DB → Cron job checks emails due in next 24hrs → Generate unique discount code per recipient → POST to Resend/Brevo API with template + variables → Webhook from email provider updates send status in DB A simple cron job polling a scheduled_emails table once per hour is enough to start — no need for anything complex until volume demands it. Quick summary Holiday data: self-host Nager.Date via Docker + Calendarific for gap countries — near zero cost to start Email sending: Resend free tier to start, move to Amazon SES when volume grows Countdown timers in email: Sendtric or Motion Mail, free tier available Scheduler: simple cron job on existing server to begin with Total infrastructure cost to launch this well could genuinely be close to zero until real email volume kicks in. Happy to go deeper on any of this — especially the non-Gregorian calendar side of Phase 4, which is probably worth scoping as its own piece of work. Really looking forward to seeing this feature ship!