Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Google says unpatched instances evaluating certain local Canadian time zones in Alberta, British Columbia, Manitoba, and the Northwest Territories may lag by one hour; stored timestamp data is not changed.
- MySQL and PostgreSQL have different maintenance-version thresholds. The MySQL default_time_zone instance flag requires a restart and is not a session-only, restart-free setting.
- PostgreSQL's ALTER DATABASE time zone default applies to new sessions; existing connection pools and role-specific settings need separate review.
- SQL Server uses the Windows time-zone names in Google's mapping. Confirm the instance, engine, and current version before making a controlled change and validating queries.
What the notice covers and when the effect starts
Google's October 30, 2026 Cloud SQL notice says that, starting at 2:00 a.m. local time on November 1, unpatched MySQL, PostgreSQL, or SQL Server instances that evaluate certain local Canadian time zones may lag by one hour. It names Alberta, British Columbia, Manitoba, and the Northwest Territories, with Calgary, Edmonton, Vancouver, and Winnipeg as examples. Google also says stored timestamp data is not modified.
The notice separately says to apply a fix before November 1. Treat 2:00 a.m. as the stated impact onset, not as an extra hour for remediation; the local times do not combine into one UTC cutoff. The notice concerns certain local time zones, not every Canadian region or database, and it does not provide an exhaustive list of affected IANA zone identifiers.
Confirm whether each instance is actually in scope
For each candidate, check the database engine, instance and maintenance version, and whether the application relies on database functions to calculate, schedule, or display local times for the named areas. An instance's location alone does not prove that it uses an affected local time zone. A project can also contain different engines, versions, and session settings.
Focus on jobs, reports, and application queries that depend on local wall-clock time. The notice does not say timestamp data will be rewritten, but calculations or displays using an affected local zone can still differ by an hour. Do not batch-change settings based only on an instance name or a customer's location when there is no evidence of the actual time-zone use.
Cloud SQL for MySQL: maintenance version and session settings
The notice recommends self-service maintenance to the latest maintenance version. The qualifying threshold for the updated time-zone rules is *.R20260726.00_36 or later. The wildcard represents a release family, so check the target instance's actual MySQL major version, installed maintenance version, and available target before acting. If the primary has read replicas, review their versions and maintenance plan together.
Do not describe the default_time_zone flag as session-only or restart-free. Cloud SQL's flag reference lists it as an instance database flag that requires a restart. For a case where an instance cannot be restarted before maintenance, the references separately describe setting the session time_zone with SET time_zone together with init_connect. That is an actual session-setting path, not the same operation as changing default_time_zone. Google's notice gives fixed-offset examples of UTC-06:00 for Alberta, UTC-07:00 for British Columbia, and UTC-05:00 for Manitoba. It does not give a MySQL fixed-offset example for the Northwest Territories, so do not infer one.
Cloud SQL for PostgreSQL: defaults apply to new sessions
The PostgreSQL maintenance threshold is *.R20260712.01_44 or later. As an alternative setting, the notice gives ALTER DATABASE database_name SET timezone TO 'anchor_zone' and names permanent-offset anchors: America/Regina (UTC-06:00) for Alberta and the Northwest Territories, America/Whitehorse (UTC-07:00) for British Columbia, and America/Coral_Harbour (UTC-05:00) for Manitoba.
PostgreSQL documentation says a database-level session default takes effect when a new session starts, and only the database owner or a superuser can change it. Existing sessions in a connection pool do not switch automatically, and a role-specific default can override the database setting. Plan a controlled connection refresh and verify new and existing sessions separately; do not claim that the database default changed every live connection.
Cloud SQL for SQL Server: use the Windows time-zone names
Google's notice does not specify a SQL Server maintenance-version threshold. It recommends changing each applicable instance's time zone through the instance Time zone setting in the Google Cloud console or with the --time-zone parameter of gcloud sql instances patch. Use the Windows time-zone identifiers in the notice's mapping; do not substitute IANA zone names.
The listed mappings are Pacific Standard Time to Yukon Standard Time (UTC-07:00) for British Columbia; Mountain Standard Time to Canada Central Standard Time (UTC-06:00) for Alberta and Inuvik in the Northwest Territories; and Central Standard Time to Eastern Standard Time (Mexico) (UTC-05:00) for Manitoba.
Validate through a controlled change
Record each candidate's engine, maintenance version, actual time zone, replica relationship, and the queries that depend on it. Then choose the maintenance update or configuration path for that engine. Treat a maintenance update as a managed change under the team's normal change controls. The cited material does not guarantee zero downtime for every instance or define one maintenance window that fits every project.
After the change, query the database session time zone and conversion results, then have the application team check new connections, connection pools, scheduled jobs, report displays, and alerts around the transition. Validate a limited scope before expanding to confirmed affected instances. Do not bulk-rewrite historical timestamp data or treat 2:00 a.m. as extra remediation time.
Sources
Frequently Asked Questions
Does an application that uses UTC need to take the same action?
Using UTC alone is not a reason to batch-change settings or ignore the notice. Check whether reports, exports, or scheduled jobs still convert UTC to a local zone covered by the notice. Without such a dependency, the notice alone does not establish that the instance is affected.
How can I check that a PostgreSQL connection-pool refresh used the intended default?
Open a new connection with the database role the application actually uses, then check its session time zone and a relevant time-conversion query. An administrator's connection does not replace that check. Review role defaults and any settings the application sends when opening a connection.
If it is already past 2:00 a.m. locally, should I backfill every historical record?
Do not backfill automatically. Establish the actual error scope, correct affected time calculations, and check for jobs that ran at the wrong time or were missed. The notice does not instruct users to bulk-rewrite stored timestamps; review business records against actual evidence.