British Columbia and Alberta permanent time change (Nov 1, 2026): impact on Confluent Cloud and Confluent Platform – Confluent Support Portal

Summary

British Columbia and Alberta have moved to permanent time. British Columbia (America/Vancouver, alias Canada/Pacific) now observes permanent UTC-7 (IANA tz database release 2026b), and Alberta (America/Edmonton, alias Canada/Mountain) now observes permanent UTC-6 (release 2026c). The abbreviations for these zones are now MST and CST.
The tz database applies both changes on November 1, 2026 at 02:00 local time, the date on which clocks would otherwise have been set back. Software that uses outdated time zone data will apply an incorrect offset from that point onward, so local dates and hours are off by one hour.
Kafka record timestamps are stored in UTC and are not affected. Only conversions that use a named British Columbia or Alberta time zone are affected. Data written before November 1, 2026 is not affected and does not need to be reprocessed.
See the impacted component details below.
Code that parses time zone abbreviations (for example PST, MST, MDT or CST) instead of IANA zone IDs may also behave unexpectedly.

Impacted components

This article applies only to configurations and code that use a named British Columbia or Alberta time zone (America/Vancouver, Canada/Pacific, America/Edmonton or Canada/Mountain), or that rely on a default time zone set to one of these. Workloads that use UTC are not affected.

Component	Impact	Customer action (Confluent Cloud)	Customer action (Confluent Platform)	Validation
Core Kafka / Metrics API / billing / audit logs	No impact is expected. Record timestamps, retention, log rolling, offsets and transaction timeouts are based on UTC or elapsed time.	None	Not applicable	Not applicable
Connect	Storage sinks (S3, GCS, Azure Blob) using `TimeBasedPartitioner`: files may be written to the wrong day or hour folder. No data is lost or duplicated. The settings `timezone`, `path.format`, `rotate.schedule.interval.ms` and `partition.duration.ms` are affected. Database connectors (`db.timezone`): local date and time values may be off by one hour. The time zone data of the database server can also be a factor. Debezium and other connectors that resolve zone names through the JVM: the same one-hour offset error may occur. HTTP connectors: affected only if the connector uses a named British Columbia or Alberta zone, or the JVM default zone, to format or parse timestamps (for example in URL or body templates, or in offset patterns). Salesforce connectors: affected only if the connector uses a named British Columbia or Alberta zone, or the JVM default zone, to convert or format date and datetime fields. SMTs: the stock `TimestampConverter` SMT does not provide a `timezone` property. Custom and third-party SMTs rely on the JVM or on the time zone data of any bundled library. Confluent Platform with no time zone configured: the JVM or operating system default zone is used, and it is affected if it is a British Columbia or Alberta zone.	Storage sinks, database connectors, Debezium, HTTP, Salesforce and other connectors: no action is required after Confluent updates the runtime. For database connectors, also verify the time zone data of the database server. SMTs: verify the transform configuration. Custom SMTs: upgrade any bundled library that includes time zone data to tzdb 2026c or later, rebuild the SMT and upload the new version.	JDK: upgrade to a build that includes tzdb 2026c or later (which includes 2026b), or to a vendor backport. For Oracle JDKs, use `tzupdater`; for OpenJDK distributions, install the latest patch release. Updating only the operating system `tzdata` package is not sufficient. Storage sinks: also upgrade to a connector release that includes the updated time zone data. Debezium, HTTP, Salesforce and other connectors: upgrade the JDK as described above. Database connectors: verify the time zone data of the database server. SMTs: verify the transform configuration. Custom SMTs: upgrade any bundled library that includes time zone data to tzdb 2026c or later, rebuild the SMT and redeploy it. After any update: restart the Connect workers.	Configuration search: search configurations and plugins for the zone IDs listed above and for the settings `timezone` and `db.timezone`. Test record: send a test record with the timestamp `2026-11-02T06:30:00Z` (Alberta) or `2026-11-02T07:30:00Z` (British Columbia). The expected local time is 00:30 on November 2. With outdated time zone data, the result is 23:30 on November 1: storage sinks write the record to the wrong folder, and other connectors and SMTs return a shifted value. Runtime check (Confluent Platform): in `jshell`, run `java.time.ZoneId.of("America/Edmonton").getRules().getOffset(java.time.Instant.parse("2026-11-02T06:30:00Z"))`. The expected result is `-06:00`.
Custom connectors	Confluent updates the Connect runtime JVM. Time zone data bundled inside your own plugin (for example, Joda-Time) is not updated by Confluent and must be upgraded by you.	Search the plugin dependencies for libraries that ship their own time zone data. Upgrade them to tzdb 2026c or later, rebuild the plugin and upload the new version.	Search the plugin dependencies for libraries that ship their own time zone data. Upgrade them to tzdb 2026c or later, rebuild the plugin and redeploy it.	Same as for Connect
ksqlDB	Kafka record timestamps and windowing use UTC and are not affected. Only queries that pass a named Alberta time zone (America/Edmonton, Canada/Mountain) to FORMAT_TIMESTAMP, PARSE_TIMESTAMP, STRINGTOTIMESTAMP, TIMESTAMPTOSTRING (3-argument form) or CONVERT_TZ are affected: results are off by one hour from November 1, 2026. These functions use the JDK's time zone data, so outdated data also affects British Columbia zones. Queries that rely on the default zone are covered under Confluent Platform.	Use the fixed offset -06:00 instead of an Alberta zone ID, for timestamps on or after March 8, 2026.	Use the JDK version that includes tzdb 2026c or later (Oracle JDK: tzupdater), then restart the ksqlDB servers. Updating only the OS tzdata package is not sufficient. Also check queries that rely on the JVM default zone (2-argument TIMESTAMPTOSTRING, TIMESTAMP_FORMAT strings with no zone): they are affected if the default zone is a British Columbia or Alberta zone.	Search queries for the zone IDs (America/Vancouver, Canada/Pacific, America/Edmonton or Canada/Mountain). Run SELECT FORMAT_TIMESTAMP(PARSE_TIMESTAMP('2026-11-02 06:30', 'yyyy-MM-dd HH:mm', 'UTC'), 'yyyy-MM-dd HH:mm', 'America/Edmonton') FROM <stream> EMIT CHANGES LIMIT 1;. The expected result is 2026-11-02 00:30. With outdated data, it is 2026-11-01 23:30.
Flink SQL	Affects Flink SQL statements that use an Alberta or British Columbia time zone (America/Edmonton, Canada/Mountain, America/Vancouver or Canada/Pacific) as the session time zone or as an explicit zone argument. Without the new time zone rules, local times in these zones are one hour off from Nov 1 2026. Affected: casts between TIMESTAMP_LTZ and TIMESTAMP/DATE/TIME/STRING, DATE_FORMAT, UNIX_TIMESTAMP, FROM_UNIXTIME, CONVERT_TZ, FLOOR/CEIL, EXTRACT/HOUR/DAYOFMONTH, day-sized TUMBLE/HOP/CUMULATE windows and LOCALTIMESTAMP/LOCALTIME/CURRENT_DATE/CURRENT_TIME. CURRENT_TIMESTAMP, NOW() and CURRENT_ROW_TIMESTAMP() are only affected in how their value is displayed. Customer UDFs that work with time zones may also be affected.	No action needed for Flink SQL statements. Confluent has updated Flink with the new time zone rules. If a statement converts a fixed date or time into Alberta or British Columbia time, stop it and create it again so it picks up the new rules. If you use UDFs, check their dependencies. Libraries such as Joda-Time or ICU carry their own time zone rules and are not covered by the Confluent update. Move them to a version that includes tzdata 2026c or later.		SELECT CONVERT_TZ('2026-11-02 06:30:00', 'UTC', 'America/Edmonton'); should return 2026-11-02 00:30:00. With the old rules it returns 2026-11-01 23:30:00. SELECT CONVERT_TZ('2026-11-02 06:30:00', 'UTC', 'America/Vancouver'); should return 2026-11-01 23:30:00. With the old rules it returns 2026-11-01 22:30:00.
Schema Registry, Stream Catalog and Schema Registry clients (serializers, deserializers and converters)	Confluent Cloud Schema Registry and Stream Catalog: not affected. Schema registration, lookup, compatibility checks and catalog search do not use British Columbia or Alberta time zones. Schema Registry server (Confluent Platform): the only default-zone effect found is log timestamps, which are off by one hour if the server’s default zone is a British Columbia or Alberta zone. Avro and Protobuf serializers and converters: dates and times are handled in UTC, so they are not affected. JSON Schema serializer, deserializer and converter: they include an older Joda-Time version through `jackson-datatype-joda`, and by default write Joda date-time values as epoch milliseconds, which is not affected. Applications can be affected if their code creates, converts or formats Joda date-time values in a British Columbia or Alberta zone, or if they set `json.write.dates.iso8601=true` and serialize Joda values in one of these zones.	Schema Registry and Stream Catalog: none. Client applications that use the JSON Schema serializer, deserializer or converter with Joda date-time types: same as Confluent Platform.	JSON Schema client applications (either case under Impact): override `joda-time` to 2.14.3 or later in your build. A later Confluent Platform release will include it. Schema Registry server: no action is needed for schema operations. To keep log timestamps correct when the server’s default zone is a British Columbia or Alberta zone, upgrade the JDK as described for Connect, then restart Schema Registry.	Joda-Time version: check which version your application resolves, for example with `mvn dependency:tree -Dincludes=joda-time:joda-time`. Version 2.14.3 or later has the new rules. Runtime check: in `jshell --class-path <joda-time jar from your application>`, run `org.joda.time.DateTimeZone.forID("America/Edmonton").getOffset(org.joda.time.Instant.parse("2026-11-02T06:30:00Z"))`. The expected result is `-21600000` (-06:00). With outdated data, it is `-25200000` (-07:00).