Maintained with ☕️ by
IcePanel logo

Starting November 1, 2026, at 02:00 a.m. local time, unpatched Cloud SQL for MySQL

Share

Services

## Announcement Announcement Starting November 1, 2026, at 02:00 a.m. local time, unpatched Cloud SQL for MySQL instances that evaluate certain local Canadian time zones (across Alberta, British Columbia, Manitoba, and Northwest Territories) will lag by one hour because the instances still follow the autumn fall back schedule. Stored timestamp data isn't modified. **What should I do?** Before November 1, 2026, do one of the following fixes: * **Apply self-service maintenance (Recommended):** If your applications rely on database functions to calculate, schedule, or display times in these Canadian time zones (such as Calgary, Edmonton, Vancouver, or Winnipeg), then update your instances to the latest maintenance release using the Google Cloud console or the gcloud CLI. Updated time zone rules that reflect permanent standard daylight offsets across Alberta, British Columbia, Manitoba, and Northwest Territories are supported in Cloud SQL for MySQL [maintenance release \*.R20260726.00\_36 or later](https://cloud.google.com/sql/docs/mysql/maintenance-changelog). For more information, see[Perform self-service maintenance](https://cloud.google.com/sql/docs/mysql/self-service-maintenance). * **Database configuration stopgap:** If your organization can't restart instances before November 1, 2026, then you can set the time zone for your database session without causing downtime for your instance. Set the `default_time_zone` flag for the database session to your target fixed numeric offset (for example, `'-06:00'` for Alberta, `'-07:00'` for British Columbia, or `'-05:00'` for Manitoba). For more information about configuring database flags, see[Configure database flags](https://cloud.google.com/sql/docs/mysql/flags).