Sunday the clocks went back. Monday the team calendar on your phone says practice is at 4:00 when it has been at 5:00 all season, and every game for the rest of the year has slid with it. Your dentist appointment is still right. Your work meetings are right. Only the calendar you subscribed to from the team app is wrong, and it was right last week.
This page is about that exact case: a subscribed calendar that was correct, then shifted by one hour on the weekend of a daylight-saving change. It is not a phone setting, and your phone is almost certainly doing the right thing. If your team calendar has been off by some hours all season, or all-day events land on the wrong day, that is the general version, covered in our guide to a subscribed calendar showing the wrong times.
A calendar link is a text file, and every event in it has a start time written one of three ways: as a bare clock time with no zone, as a clock time tagged with a named zone, or as a UTC time. A named zone is supposed to come with a block of rules in the same file, the VTIMEZONE, that says when the zone springs forward and falls back. Your phone reads the file, applies those rules, and shows the result. When the file is written properly, the clocks changing is a non-event: 5:00 PM stays 5:00 PM on both sides of the weekend.
The one-hour shift appears when the file is not written properly, in one of three ways. The feed carries a named zone but a degenerate VTIMEZONE, one with a single offset and no daylight rules, so the reader applies that one offset year-round. Or the feed writes each event in UTC, and the publisher computed that UTC with a fixed offset, so the UTC values themselves are an hour wrong for half the year. Or the feed writes bare clock times that were produced by converting from the publisher's database with an offset that is only correct in summer. In every case the file is right from March to November and wrong from November to March, or the reverse, and it flips on the weekend the clocks change. Feeds from team apps and league sites can do any of these; which one you have depends on the platform and sometimes on the club's own settings in it.
The next two weekends this matters: in the United States clocks go forward on Sunday, March 14, 2027 and back on Sunday, November 7, 2027. Not everywhere still does this. British Columbia changed its clocks for the last time in March 2026 and stays on daylight time year-round, so a feed published there with a fixed offset is now simply correct, while one that assumes the province still changes will be the one that drifts.
Two things this bug does not do, which help you rule it out. It does not move all-day events: a tournament weekend or a school holiday written as a date has no clock time to shift, so if those are landing on the wrong day you have the all-day problem from the general wrong-times guide instead. And it does not move only some events: a fixed offset is applied to the whole file, so every timed event after the change weekend shifts together. One game off by an hour is a reschedule; the whole season off by an hour is the file.
There is a two-minute way to be sure. Put an event you created yourself next to an event from the team calendar on the same day. If your own event kept its time across the weekend and the team's moved, the phone is right: it handled the change correctly for the event it fully understood, and it handled the team's event exactly as the file told it to. If both moved, the phone's time zone, or the calendar app's own time-zone setting, is what to look at, and that is the general case on the wrong-times page.
Then read the same game in the source app. The team app's own screen usually shows the right time even when its export doesn't, because the app displays from its database and the feed is a separate conversion. Right in the app, wrong on the subscribed calendar: the feed. Wrong in both: a real schedule change or a data entry error, which no calendar setting will correct and which the coach needs to hear about. One more trap: the fall time change lands in the same weeks as tournament reschedules and league playoff draws, so a game that genuinely moved an hour looks identical to one that shifted. The feed-level bug moves everything; a reschedule moves one game.
If you want to see the mechanism rather than infer it, open the calendar link in a browser (swap a webcal:// prefix for https://) and look at one event's DTSTART line. A trailing Z means UTC; a TZID= means a named zone, and you can scroll up to see whether a VTIMEZONE block for it exists and has both a STANDARD and a DAYLIGHT part; a bare time with neither is floating. You don't need to understand the file to fix the problem, but it settles the argument about whose fault it is.
Honestly: you can't fix the feed from your phone, and the settings that look like they might will break everything else on your calendar. What you can do is confirm the diagnosis, get the fix made where it has to be made, and make sure your phone picks it up the moment it exists, or put a layer between the feed and your phone that handles it for you.
Confirm it is only the subscribed calendar. Look at an appointment you typed yourself and at an event from the team calendar on the same day. If yours is right and the team's is an hour off, your phone's clock and time zone are fine and the problem is in the feed. If everything is off, including your own, check the phone's time zone and the calendar app's own time zone setting instead — that's the general case, covered in our wrong-times guide.
Check the time in the source app. Open the team app or league site and read the same game there. If the source shows the right time and the subscribed calendar shows it an hour off, the export is the problem, not the schedule. If the source is wrong too, the coach or league entered it that way and no calendar setting will fix it — tell them.
Tell whoever publishes the feed. The repair happens on the publisher's side. A short message to the team manager, league admin, or the app's support, saying the calendar link shows every event one hour off since the clocks changed, is usually enough; it's a known class of bug and the fix is in how times are written to the file. You can't patch it from your phone, because your phone is reading the file correctly.
Re-subscribe once the feed is fixed. A subscribed calendar only re-reads the feed on its own cycle, so even after the publisher fixes the export your phone can keep showing the old file for a day. Remove the subscription and add the same link again: a freshly added calendar is pulled immediately. On iPhone that's Calendars → the info button next to the subscription → Unsubscribe, then Add Calendar → Add Subscription Calendar. In Google Calendar it has to be done on the web.
Or put a layer in between that watches the feed for you. Paste the same calendar link into Schedule Caddie. Every feed is re-checked hourly, times are normalized when feeds are merged, and the result is one color-coded family calendar you open in any phone browser, with a Subscribe URL if you still want it inside your phone's calendar. When a game actually moves, you get an email naming the old time and the new one. When an entire feed shifts at once, the batch is held for review instead of being applied, which is how you'll know a one-hour shift was the clocks and not a reschedule. A missing or broken zone definition is repaired in the merge; a file whose clock values are themselves wrong still has to be fixed by the publisher.
The layer in step 5 is the same setup that solves the slower problem underneath this one: a subscribed calendar is only re-read on the phone's own schedule, roughly every 12 to 24 hours, and when it does update, nothing on screen says what changed. Every feed in Schedule Caddie is re-checked hourly and compared with what it said last time; a moved game produces an email with the old time and the new one. If a feed shifts an hour across the board, the whole batch is held for review rather than applied, which is itself the tell: a reschedule is one or two emailed changes, a time-change bug is a held batch. The remove-and-re-add mechanics, and the test for a feed that has gone dead rather than wrong, are in why a subscribed calendar stops updating; if the calendar vanished from your phone rather than shifted, see subscribed calendar not showing on your phone. To see what the merged calendar and the change emails look like before pasting anything, the demo is a real family's calendar, no account needed.
Partly, and not in a useful way. A feed that is wrong because of a fixed offset becomes right again the next time the clocks move the other way, in March, and wrong again the following November. Nothing about waiting changes the file. Meanwhile the phone keeps re-downloading the same wrong file on its own cycle, so even the moment the publisher corrects the export, your phone can show the old version for most of a day until it refreshes, which is why step 4 is to remove and re-add rather than wait.
The March change is worth planning for now, because it runs the same bug backwards. A feed that went an hour early in November goes an hour late on March 14, 2027, and a family that has quietly been adding an hour in their heads all winter will start arriving an hour late in spring. If you reported the problem in November and the publisher fixed it, March is also the first real test of the fix: a corrected file carries the daylight rules, so nothing should move at all that weekend. Put one known game on your own calendar by hand the week before and compare on the Monday.
What does fix it is the publisher changing how the file is written, and the practical lever for that is parents reporting it the week it happens. It is a bug that every family on the platform sees on the same Sunday, which makes it one of the easier ones to get prioritized. Until then, the copy of the schedule you trust should be one where someone is checking for changes every hour and holding a whole-feed shift back rather than quietly applying it, and the rest of the family should be looking at that same copy, through a share link that opens without an account, rather than at their own subscriptions pulling their own copies of the same wrong file. Merging the feeds repairs a missing or broken zone definition; it cannot repair a file whose clock values are wrong, and no calendar can.
When you do report it, the useful message is short and specific: the calendar link for this team shows every event one hour off since the clocks changed on November 1, the times are correct inside the app, and your own appointments are unaffected. That tells whoever reads it that the export is the problem, not your phone, and it is the sentence that gets a ticket routed to the right person instead of a reply suggesting you check your time zone.
It was fine for months, then every event jumped at once
That is the signature of this bug, and it is good news in one way: nothing on your side changed. The feed was writing times with a single fixed offset, and that offset was correct until the clocks moved. Go straight to steps 2 and 3. If you can see the raw file (open the link in a browser; swap webcal:// for https://), look for a TZID whose VTIMEZONE block has only one of STANDARD or DAYLIGHT, or no VTIMEZONE at all; that is the mechanism. A trailing Z on each DTSTART means UTC, which is fine in itself — the bug is then in how the publisher computed those UTC values.
Only some of the games are an hour off
Then the feed is probably correct and those games moved. Fall tournaments and league reschedules land in the same weeks the clocks change, which is why families blame the time change for a real shift. Check one of the odd games in the source app. If you'd put the feed through Schedule Caddie, the change email would have said old time → new time for exactly those games; that is the fastest way to tell the two apart.
I re-subscribed and the times are still wrong
Then the feed itself still carries the bug, and re-subscribing only pulled a fresh copy of the same wrong file. A parent on Apple Support Communities described the lag side of this plainly: “Schedule updates made at TeamSnap are not being updated on my phone’s calendar.” Wait for the publisher's fix, or route the link through a layer that normalizes times. Changing your phone's time zone to compensate will break every other event on it.
The times are wrong on the phone but right on the computer
Different calendar programs handle an ambiguous time differently: one may apply the zone named in the file, another may fall back to a fixed offset or to the device's own zone. Two correct readers of a broken file can disagree. That disagreement is itself the evidence that the file, not the device, is the problem. The fix is the same: upstream, then re-subscribe.
In the United States, clocks go forward on Sunday, March 14, 2027 and back on Sunday, November 7, 2027, following the rule of the second Sunday in March and the first Sunday in November at 2:00 a.m. local time. Both are weekends when a feed with this bug will shift again, in the other direction in March.
Almost never, if only the subscribed calendar is off. The phone displays what the file tells it to. A feed that writes times with a fixed offset, with a time-zone name but no rules for when that zone changes, or in UTC converted with the wrong offset, produces a file that is one hour wrong for half the year — and every correct calendar app will show it that way.
We won't name any, because it depends on how a particular platform, or even a particular club's settings on that platform, writes the file, and it changes with updates. Feeds from team apps and league sites can all do this. The test in step 1 tells you whether yours does, without needing to know why.
You can, and everything else on your calendar will then be an hour wrong instead. Google Calendar's primary time zone and the iPhone's Time Zone Override both apply to every event you see, not one feed. The general-case trade-offs are in our subscribed calendar wrong times guide; for a DST-only shift, leave them alone.
If the publisher never touches it, a fixed-offset feed goes back to being right when the clocks go forward in March, and wrong again in November. That isn't a fix; it's a six-month cycle. Report it once and it generally gets corrected; team apps have strong reasons to fix a bug every parent notices on the same weekend.
It is free, with no ads. You paste the team-app calendar links, or upload a PDF or photo when there is no link, and every kid's schedule lands on one family calendar that is re-checked hourly, with times normalized when the feeds are merged. When a game moves, the email says what moved. There is a read-only share link for anyone who drives, and a Subscribe URL for phone calendars and displays.
Every kid, every schedule, every app — merged, color-coded, and watched for changes.
Get Started FreeWant to see it first? Explore a real family's calendar — no account needed.
Prefer an interactive walkthrough? Try the guided wizard
Every schedule on one family calendar
Free · iPhone, Google or Outlook · one email when anything moves