SAP SuccessFactors Learning Canada Time-Zone Alert: One-Hour Risk After November 1

Operational alert | Checked 2 November 2026 | Impact date: 1 November 2026. A scheduled Learning class that displays 9:00 a.m. when the local time is actually 10:00 a.m. is not a cosmetic defect. It can affect attendance, learner notifications, automated processes and scheduled reports. SAP's public KBA 3834267, Canadian time zones in Learning, warns that selected Canadian time-zone identifiers can show times one hour earlier than actual local time after the 1 November 2026 daylight-saving transition. The KBA remains relevant even though some patches were planned for October, because SAP explicitly warns that pre-existing classes and jobs may still require manual review.

Evidence and status: This is an SAP-documented risk, not proof that every Canadian SAP SuccessFactors tenant is currently defective. SAP's public KBA does not expose an exact publication or last-update date in its readable page. Its effective impact date is 1 November 2026, and this article reports the KBA's visible status as checked on 2 November. Planned deployment dates are not evidence that a particular tenant received a fix.

Which Learning time zones does SAP identify?

The SAP KBA names eight identifiers: America/Edmonton, America/Inuvik, America/Vancouver, America/Winnipeg, America/Yellowknife, Canada/Central, Canada/Mountain and Canada/Pacific. The risk arises where a province or territory no longer moves clocks back in November, while the Java time-zone definitions used by the Learning application still expect the old seasonal transition. This can result in the displayed or calculated time being one hour behind the legally observed local time.

The civil-time change is independently confirmed. The British Columbia government announced permanent year-round daylight time after the March 2026 spring change, with no fall-back on 1 November. The Manitoba government confirms that its new Manitoba Standard Time is UTC-5 year-round and that clocks did not move back on 1 November. This is not a Canada-wide rule: many other jurisdictions still observe a seasonal change. Validate the actual location, not just the word 'Canada' in a user profile.

Patch status: October dates for some zones, TBD for others

SAP lists planned fix dates of 12 October 2026 in SaaS Preview, 23 October in SaaS Production/SalesDemo, and 24 October across the listed VSaaS environments for America/Edmonton, America/Vancouver, America/Yellowknife, Canada/Mountain and Canada/Pacific. For America/Inuvik, America/Winnipeg and Canada/Central, the public KBA still shows TBD for the environments in its table. That is an unresolved published timetable, not independent proof that a specific tenant has no patch. Confirm the deployed correction with SAP and test the affected tenant directly.

Do not assume that a platform correction repairs historical scheduling data. SAP explicitly says the fix addresses time-zone behavior going forward but does not automatically update existing entities or jobs created before the fix and scheduled after the transition. This is the detail most likely to be missed in a release-only test plan.

Immediate admin test: find the classes that may be one hour wrong

In Learning Administration, first check your own time-zone preference and whether Always display Classes in this Time Zone is selected. Then go to Learning Activities > Classes, filter Start Date After: 1 November 2026, and include location, security domain and item criteria where useful. Add the columns Class ID, Title, Item/Resource Block, Start Date/Time, End Date/Time and TimeZone, then export the result. These are the identification steps documented in KBA 3834267.

Compare each relevant class against the legally observed local time for its venue, the instructor's calendar invitation and any learner-facing notification. Do not rely only on the administrator's display: a preference can change the apparent time without changing the underlying class record. Prioritize classes starting this week, recurring sessions, compliance training, instructor-led events and anything with attendance or payroll consequences.

Workarounds SAP describes, and the risks of applying them blindly

Where the affected identifier is not corrected, SAP describes temporarily choosing a fixed-offset zone with the same legally observed UTC offset. Its examples are America/Phoenix for UTC-7, America/Regina for UTC-6 and America/Panama for UTC-5. In a class, administrators can change Class Time Zone in Details or edit time slots in the Agenda. SAP also refers to the Class Connector for mass updates. These are temporary options, not instructions to replace every Canadian time zone across an entire tenant.

Before changing anything, preserve the original zone and local time, test one representative class in a nonproduction environment where feasible, and confirm the result from both administrator and learner perspectives. For a large correction, obtain the learning process owner's approval and maintain a reversible change log. Avoid bulk rewrites where the current tenant is already patched or where the class belongs to a location that still follows a seasonal transition.

Classes are not the only exposure: check automated processes and reports

SAP warns that scheduled/running jobs, automated processes, classes and scheduled reports using affected zones may occur at unexpected times. That makes the risk operational rather than purely visual. Audit Learning automatic-process schedules, recurring reports, class notifications and any downstream integration that consumes local timestamps. Record both the intended local time and the actual execution time in UTC, then compare them with the province's new offset.

For example, Manitoba's official UTC-5 year-round rule means that a recurring job intended for 9:00 a.m. local time should be evaluated against 14:00 UTC, not the former winter-time UTC-6 conversion. This is a conversion example, not evidence of a particular customer's misfire. The Manitoba government also advises organizations to check scheduled integrations and recurring calendar events. Where a Learning class feeds an external calendar, retest the complete notification and registration path.

My recommended 24-hour response for Learning teams

First: identify whether the tenant has learners, classes or jobs using the eight SAP-listed identifiers. Second: export future classes and the next execution times of affected automatic processes. Third: test local-to-UTC conversion against an authoritative provincial clock and record discrepancies. Fourth: open or update an SAP support case for any zone whose fix status remains uncertain, referencing KBA 3834267 and the specific environment. Fifth: apply only approved, scoped corrections, and inform instructors and learners when a confirmed event time changes. Sixth: recheck schedules after any vendor patch because existing entities may not self-correct.

For issues in Employee Central, Time Management, Recruiting or other SuccessFactors modules, do not automatically extrapolate this Learning-specific KBA. SAP says to contact the responsible module's support team for their scope. A Learning issue can expose a wider integration problem, but each product's time-zone behavior must be verified independently.

What is confirmed, and what is still unknown?

Confirmed: the 1 November 2026 Canadian civil-time changes in the affected jurisdictions, SAP's documented Learning risk, its listed time-zone identifiers, the planned dates for one group and TBD status for another, and the need to review pre-existing classes and jobs. Not confirmed: that every planned patch actually reached every tenant, the date SAP last edited its public KBA, or that a particular customer's schedule is wrong. Those are tenant-specific verification items, not facts to invent.

Architect's takeaway: a time-zone patch can be technically successful while a business process remains wrong. For Learning, the acceptance test is not merely 'the platform has the latest fix.' It is that the learner, instructor, class record, automated process and external calendar all agree on the correct local time after 1 November 2026.