I previously wrote about a critical wide-open remote security vulnerability that I discovered in Mysa thermostats in February 2025. I’m also the author of mysotherm, a small project of mine that has become the de facto reference guide to how Mysa smart thermostats communicate over the network.

What I am writing about here is not a security vulnerability. It’s just a really annoying and careless bug. I mention the prior mainly just to emphasize that I know what I’m talking about.

tl;dr

Mysa screwed up the change to the timezone used by most of the population of British Columbia in 2026. As a result, everyone in British Columbia with a Mysa thermostat probably has their thermostat’s schedules off by an hour, and is probably confused by puzzling offsets when trying to edit this in the app.

The change to BC’s timezone was announced on March 2, 2026. As of November 2026, BC will no longer switch between summer time (“daylight savings time”) and winter time (“standard time”) twice a year, but will remain on what was previously its summer time.

In terms of a concrete divergence, it happened at 2026-11-01T10:00:00Z¹, when the local clocks used on the West Coast of the USA (e.g. Portland or Los Angeles) “fell back” by an hour, but the local clock used in most of BC did not change.

Despite having nearly 8 months’ worth of advance notice of this change to BC’s timezones, Mysa didn’t update its devices’ firmware² correctly, so all Mysa users who had their devices’ timezones set to America/Vancouver³ now have their devices’ schedules off by an hour.

Timezone bugs are really annoying

I feel like I spend a good chunk of my time at $DAYJOB dealing with timezone and clock-skew bugs in industrial systems, and I’ve had similar experiences at previous jobs.

A very tiresome obstacle to dealing with bugs related to daylight savings time shifts is that you first have to establish a consistent definition of exactly what a timestamp means, with respect to some fixed source that doesn’t shift.

I can’t remember how many times I’ve had to spent hours or days teaching or arguing about the definitions of time, timezones, daylight savings time, and timestamps before I can convince someone to fix a timezone-handling bug, often by storing timestamps exclusively in a timezone-aware format.

How Mysa thermostats handle time and timezones

Mysa thermostat devices mostly communicate timestamps in the format of seconds since the Unix epoch. This is not a human-friendly format, but it contains no ambiguity with respect to local timezones.⁴ That’s useful.

However, Mysa thermostats can also follow a schedule based on local time, so they need to be configured to know the local timezone where they’re installed.

For example, we configured the thermostat in our son’s room to heat it up from 7-8pm every day, around his bedtime, and then to cool off after he’s asleep.⁵

You can read the gory details in my Mysa MQTT message docs, but basically the Mysa thermostats define recurring weekly schedules in terms of minutes since midnight on Sunday in the local timezone. That is, if I want my son’s room to heat up at exactly 7:00pm local time every day of the week, Mysa’s mobile apps and servers communicate this to the thermostat as a sequence of 7 weekly events occurring at:

• 1140 minutes (= 19 hours since midnight Sunday = 7:00pm on Sunday)
• 2580 minutes (= 43 hours since midnight Sunday = 7:00pm on Monday)
• 4020 minutes (= 67 hours since midnight Sunday = 7:00pm on Tuesday)
• …
• 9780 minutes (= 7:00pm on Saturday)