A recent, still unanswered Moodle community forum thread shows why the Moodle 5.1 Alberta time change is harder than it looks. The administrator was running Moodle 5.1.6 on PHP 8.3.33 and had installed timezone database 2026.3 for Alberta’s change. The calendar still shifted from UTC-6 to UTC-7 between November and December, and a second site on Moodle 5.2 did the same. Updating the timezone data is the fix everyone reaches for first. It is necessary, but it is not sufficient.
For a professional association, however, the calendar page is the smaller worry. The real exposure is every deadline a member’s credential depends on: CE due dates, renewal cutoffs, exam windows and certificate expiry. Here is what the Moodle 5.1 Alberta time change does to dates already stored, and how to audit them and tell members before 1 November.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- What Alberta’s Permanent Daylight Time Change Means for Dates Stored in Moodle
- Why Updating the Timezone Database Alone Doesn’t Fix It: The Calendar Still Misreads Future Dates
- The Deadlines at Risk for an Association: CE Due Dates, Renewal Cutoffs, Exam Windows, Certificate Expiry
- Auditing Member-Facing Dates and Telling Members What’s Changing
- How Mindfield Helps Alberta Associations Test and Fix the Change
- Frequently Asked Questions (FAQs)
What Alberta’s Permanent Daylight Time Change Means for Dates Stored in Moodle
Alberta’s transition to permanent daylight time in 2026 introduces a critical shift in how Moodle sites manage and display dates. This change means the province will observe a single year-round time, specifically a UTC-6 offset. For Moodle, the dates that matter are the ones saved before a server knew about it.
The IANA Time Zone Database Update
The IANA time zone database, the source of the rules PHP and Moodle rely on, modelled Alberta’s shift. Release 2026c (July 8, 2026) codified this as a permanent UTC-6 offset. This change takes effect on the clock at 02:00 on November 1, 2026, using the abbreviation CST.
Later, release 2026d (September 11, 2026) extended the same rule to the portion of the Northwest Territories not already following Alberta’s time zone. The rest of the territory already follows Alberta’s zone and changed with it.
How Moodle Handles Dates and Times
Moodle stores every date as a single, universal instant, known as a Unix timestamp. When a coordinator types a date and time into a date picker, Moodle converts that wall-clock time into this universal instant. It uses the timezone rules the server had at that moment and the editing user’s timezone setting.
When a member views that date, Moodle recomputes it for their specific timezone. This process means the underlying instant does not change, only its display. The wider decisions, such as forcing one site timezone, are covered in our guide to optimizing Moodle timezone settings.
Which Moodle 5.1 Dates the Alberta Time Change Puts at Risk
The only dates truly at risk are those falling on or after November 1, 2026, within what used to be the winter period (November to mid-March each year). These dates are only affected if they were saved before the Moodle server received the new time zone rule. Summer dates, from mid-March to October, remain unaffected because both the old and new rules align on a UTC-6 offset during those months.
Therefore, on a Moodle 5.1 site, the Alberta time change is a winter-deadline problem.
Why Updating the Timezone Database Alone Doesn’t Fix It: The Calendar Still Misreads Future Dates
Many Moodle administrators first attempt to resolve timezone discrepancies by updating the server’s timezone database. That is necessary but not sufficient, because the problem sits in two places: the rules on the server and the dates already saved.
The Layered Nature of Time Zone Rules
Moodle does not directly manage time zone rules itself. Instead, it reads its time zones from PHP. PHP, in turn, ships with its own compiled-in copy of the IANA database.
Therefore, simply updating the operating system’s time zone data does not necessarily update PHP’s copy. The PECL timezonedb extension is a drop-in replacement. It allows administrators to obtain a later version of the time zone database than what ships with PHP.
Its current release is 2026.4; see PECL timezonedb. No Moodle setting reaches this layer.
Ensuring the Update is Active Across All Moodle Processes
An update to PHP’s time zone data only takes effect where the site actually runs it. This is a critical distinction. The web pages members see might run under one PHP configuration.
However, scheduled tasks that send reminders and notifications can operate under a different configuration. Furthermore, a newly installed extension is not active until the PHP service serving the Moodle site has been restarted. So, proving “we installed it” and “the site is using it” requires separate verification steps.
The Persistent Impact on Already Stored Dates
Even when the time zone database update is fully in effect, dates saved before the update will remain incorrect. This is the part nobody expects. Consider an Alberta coordinator who sets a renewal cutoff for 11:59 PM on December 31.
Here is how that one date travels:
- Typed: 11:59 PM on 31 December, Alberta time.
- Stored under the old rule (December at UTC-7): 6:59 AM UTC on 1 January.
- Displayed under the new rule (UTC-6): 12:59 AM on 1 January, so the cutoff now reads as falling in the next year.
Therefore, the fix has two halves: current rules on the server, and a review of every date already stored. The sooner the server is current, the smaller the audit.
The update itself makes the old error visible.
The Deadlines at Risk for an Association: CE Due Dates, Renewal Cutoffs, Exam Windows, Certificate Expiry
For a professional association, the Moodle 5.1 dates the Alberta time change puts at risk are the ones a member’s credential depends on. Most of these affected deadlines are typically set near midnight on the last day of a cycle or month.
This is precisely where a one-hour shift can inadvertently move a date into the next day or year, altering its intended meaning.
| Date Category | Where it lives in Moodle | What an hour late does |
|---|---|---|
| CE activity due/cut-off dates | Assignment due date, cut-off date | A submission an hour past the intended cut-off is accepted, or a member is told one time and held to another. |
| Renewal and CE-cycle cutoffs | Enrolment end dates, course end dates, date-based access or completion conditions | Credits earned in the extra hour land on the wrong side of a CE cycle, which becomes an audit question. |
| Exam windows | Quiz open and close times | The window opens and closes an hour later than published; a timed attempt ends at the earlier of the time limit or the close time, so members are sitting a different window than the one announced. |
| Certificate and badge expiry | Moodle badges fixed expiry, certificate plugin expiry dates | An hour late rarely matters on its own, but a date near midnight moves to the next day, affecting credential validity. |
| Calendar events and dated announcements | Course calendar events, activity announcements | The Moodle site shows one time, while the email or PDF the association sent says another, creating confusion. |
Impact on CE Activity and Renewal Cycles
CE due dates and renewal cutoffs are where an hour does the most damage:
- Cut-off dates: a submission an hour past the intended cut-off is still accepted, while a member who read the deadline in an email works to a different time from the one the site enforces.
- Renewal and CE-cycle cutoffs: set through enrolment end dates or date-based access conditions, a 31 December cutoff that reads as 1 January puts credits earned in that extra hour in the wrong cycle. For an association, that is an audit question.
For more on managing CE, see continuing education management in Moodle.
Exam Windows and Certificate Expiry
Exam windows, set by quiz open and close times, also face disruption. An exam window might open and close an hour later than published. Members therefore sit a different window from the one announced.
Furthermore, Moodle badges can carry a fixed expiry date. Where one of the Moodle certificate plugins stores an expiry date, the same logic applies. While an hour late might not always be critical, a date near midnight could push the expiry into the next day, potentially affecting a member’s credential validity.
The same goes for the due dates that Moodle assignment notifications announce to members.
Auditing Member-Facing Dates and Telling Members What’s Changing
Responding to the Alberta time change on Moodle 5.1 has two halves: an audit of affected dates and a clear notice to members. Both belong before 1 November.
Auditing Moodle 5.1 Dates After the Alberta Time Change
An audit should be comprehensive and strategic, not merely reactive. The scope must specifically target dates on or after November 1, 2026, which fall within the winter period (November to mid-March) and were saved before the server had the new rule. Dates saved after the update and all summer dates are generally not at risk.
The audit comes down to five decisions:
- Inventory every dated item: Look beyond the calendar page. This includes activities, enrolments, completion and access conditions, badges, certificates, scheduled reports, and calendar events across all courses.
- Prove server currency first: Confirm the running Moodle site actually has the new time zone rule in effect. Only then can you accurately assess existing dates.
- Review against intent: Check each affected date against the association’s intended deadline, as stated in published policies or member communications. Do not simply compare it to what the screen currently displays.
- Records owner sign-off: The designated records owner, such as the registrar or CE lead, must formally sign off on the list of audited and corrected dates. This ensures accountability and accuracy.
- Retain audit evidence: Keep the before-and-after list of changes with the association’s audit evidence. Future audits may inquire about CE cycles that spanned this time change. For more on this, consult Moodle data retention for professional associations.
Clear Member Communication Strategy
Transparent and timely communication is vital to prevent member confusion and maintain trust. The key is to convey the change plainly and specifically. When communicating with members:
- Explain the local impact: For Alberta members, nothing changes on their wall clock on November 1. However, for members in regions that still observe daylight saving time, the time gap to Alberta will change by an hour. This distinction must be clear.
- Avoid bare abbreviations: Never use a bare time zone abbreviation like “CST.” The province refers to it as permanent daylight time, and the database uses CST for the same moment. Members’ phones and calendar apps may display either. Always write the full date, time, and specify “Alberta time.”
- Promote calendar subscriptions: Encourage members to subscribe to their course calendars. Moodle’s calendar export writes event times in UTC, allowing a member’s own calendar application to convert it correctly without any manual adjustments.
- Verify reminder emails: Reminder emails are sent by scheduled tasks on the Moodle server’s clock. After the audit and any date corrections, verify that the reminder a member receives names the same time the site shows. This prevents confusion. For issues with reminders, consult Moodle assignment deadline reminders not sent and Moodle notifications not sending.
How Mindfield Helps Alberta Associations Test and Fix the Change
Mindfield helps Alberta associations get their Moodle 5.1 sites ahead of the 1 November time change. We confirm the server is running the new rule on both the web and scheduled-task side, rehearse on a copy of the site, and produce the inventory of affected dates. We then correct those dates against the association’s intent, with the records owner signing off, and draft the member notice. For the longer-term decisions, such as forcing a site timezone or setting each member’s timezone at provisioning, see our guide to optimizing Moodle timezone settings and our Moodle support options.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
