Our managed MySQL database currently uses a parameter group with `time_zone = 'US/Pacific'`. British Columbia is moving to permanent Pacific Daylight Time at UTC−07:00, so the current timezone rules may cause the database to switch incorrectly when the seasonal clock change would normally occur in November 2026.
I upgraded the MySQL engine to a version that should support the newer timezone data, but the parameter group does not accept `America/Vancouver`. It appears the managed service only allows a limited set of timezone names. Changing the application and database to UTC would be the cleanest long-term solution, but this is an inherited system and a broad application refactor is not currently feasible.
Has anyone found a supported way to configure the database for British Columbia's new permanent offset, or another solution that avoids setting the timezone separately on every connection?
2 Answers
Is this configured in an instance parameter group or a cluster parameter group? The available settings and supported behavior can differ depending on the deployment type.
The most robust design is to keep the database in UTC and convert timestamps in the application or at the presentation boundary. That avoids relying on regional daylight-saving rules and makes future timezone changes much less disruptive.
I agree, but this is an inherited application and changing its time-handling behavior would require a large refactor that isn’t currently approved.
This is exactly the kind of problem caused by storing local time in the database. It may have seemed convenient years ago, but now the timezone rules are effectively part of the system’s business logic, so changing to UTC would require careful planning and validation.
It’s an instance parameter group. The managed service doesn’t appear to expose the full IANA timezone list, so `America/Vancouver` isn’t available.