When your GroupApp community’s timezone observes Daylight Saving Time (DST), your scheduled events may appear one hour earlier or later right after the switch. This is normal and applies to both single and recurring events. GroupApp follows industry‑standard calendar rules so your events remain aligned with the local time in your community’s timezone and with external calendars like Google, Apple, and Outlook.
DST can shift displayed event times by one hour.
GroupApp adjusts automatically to keep events at the correct local hour.
If you want a fixed “wall‑clock” time, edit the affected occurrences.
Twice a year, the local definition of time changes. In spring, clocks move forward by one hour; in fall, they move back by one hour. GroupApp recalculates display times at that moment so your events continue to happen at the correct local hour. The event didn’t “move”—the local clock did. External calendars reflect the same shift.
Spring: clocks move forward by 1 hour; Fall: clocks move back by 1 hour.
GroupApp updates the displayed start time to match the new local time.
External calendar subscriptions (Google, Apple, Outlook) stay in sync.
Example (US Eastern Time): If an event is scheduled at 2:00 PM the week before DST ends, it will display as 1:00 PM the week after the change. The event is still anchored to the community’s local time rules; the one‑hour difference reflects the seasonal clock change.
Nothing is “wrong.” The clock changed; your schedule stayed correct relative to local time.
If you haven’t crossed a DST boundary with your schedule before, the shift can be surprising. It’s also easy to miss if you’ve built events week by week or manually tweaked a few times in the past. Changes in your community timezone or member regions can make the effect more noticeable.
You may not have scheduled across a DST week before.
Manual edits can mask the automatic adjustment.
Region differences highlight the change for some members.
GroupApp applies the same DST logic to single and recurring events. Recurring series just make the change more obvious because you can view multiple future dates at once. If only specific occurrences show the “old” hour, those were manually edited and will keep that manual time.
Same rules apply to single and recurring events.
Series view surfaces the change across multiple dates.
Manually edited occurrences keep their edited time.
If your community expects a session to stay at the same wall‑clock hour year‑round (for example, always 2:00 PM local), you can pin that hour by editing the affected occurrences after the switch. Those edits persist for the dates you change.
Choose: follow local time rules vs. keep a fixed wall‑clock hour.
Edit the post‑switch (or pre‑switch) occurrences to your preferred time.
Your manual edits will stick for those specific dates.
Automatic DST handling keeps your schedule accurate and consistent across regions and calendars. Without it, events would land at the wrong local hour, cross‑timezone conversions would drift, and external calendars wouldn’t match.
Events stay aligned with the local definition of the hour.
Conversions for members in other timezones remain accurate.
Integrations with external calendars remain consistent.
Do members in other timezones see the same change?
Yes. Everyone sees events in their own local time. When your community enters or exits DST, the display updates for all members, and external calendars reflect the same shift.
Does GroupApp change my community’s timezone?
No. Your chosen timezone stays the same; only the seasonal offset changes according to that timezone’s DST rules.
Why do some dates look “off” compared to the rest of the series?
Those specific occurrences were manually edited. Manual edits override the automatic DST adjustment for that date.
What’s the best practice?
Pick a consistent approach for each series. If you want a fixed wall‑clock hour, make quick edits right after the switch so the schedule stays predictable for members.
