I agree that daylight savings time sucks, but the problem you encountered is entirely on BlueDot. Software that schedules according to UTC is, essentially, broken(*). It may be convenient or seem necessary if you are dealing with scheduling across-jurisdictions, where the jurisdictions involved schedule their DST transitions on different dates. (You did not say this was the case. Are these groups on-line, or face-to-face?) But it's still basically wrong - once all jurisdictions involved have transitioned, the schedule should return to the original nominal times. And the transition period should be handled individually, by humans, not clue-free software.
(*) Unless of course you are scheduling e.g. times to view astronomical events, or other phenomena not affected by official clock time.
I agree that daylight savings time sucks, but the problem you encountered is entirely on BlueDot. Software that schedules according to UTC is, essentially, broken(*). It may be convenient or seem necessary if you are dealing with scheduling across-jurisdictions, where the jurisdictions involved schedule their DST transitions on different dates. (You did not say this was the case. Are these groups on-line, or face-to-face?) But it's still basically wrong - once all jurisdictions involved have transitioned, the schedule should return to the original nominal times. And the transition period should be handled individually, by humans, not clue-free software.
(*) Unless of course you are scheduling e.g. times to view astronomical events, or other phenomena not affected by official clock time.
It covers multiple jurisdictions, including those that do not have DST. I don't think there is obvious solution in that case. (And it is online)
Agreed. No good solution there.