August 2026 Mugo Digest
By: Bethany Morse | August 26, 2026 | ibexadxp, Libraries, and Tales from a Developer
This year, two Canadian provinces, BC and Alberta, moved to make Daylight Saving Time permanent. This created an issue with event registrations for some of our library clients, an interesting technical solution, and the potential for future implications down the road as other provinces (and the US) potentially join the trend. This and more in August’s Mugo Digest!
We’ve added a few new features to our Mugo Library: Reservations platform over the past few months, which meant it was time to do a fresh accessibility audit. Mugo Library: Reservations is an equipment management system for libraries that makes it possible for patrons and staff to reserve special collections, like book club kits, in advance. Beyond following regulations, we strongly believe that all websites should be equally accessible to individuals. We are digital accessibility experts and want to make sure that all of our products meet or exceed WCAG 2.2 AA standards. To this point, we increased the ease of keyboard navigation within Mugo Library: Reservations. We also added a few new UX elements for the custom reservation forms. If you want to learn more about the Mugo Library: Reservations system, contact us for a demo.
The eep bundle has been updated! The new additions help support object state operations, as well as creating and exporting content types. Not familiar with eep? It’s a tool we use often here at Mugo Web, and which we support on behalf of other developers working with the eZ Publish and Ibexa products.
In March of this year, BC announced that it would no longer follow Standard Time, and would make Daylight Saving Time permanent. Come fall, times would not change. Then in June, Alberta made a similar decision. This added some complication to event listings on a few of our library sites [link marigold case study], which had already started listing events and times for fall programming. The events should have maintained the correct time, thanks to tzdata (the Time Zone Database), which the site used to calculate time. However, on the site, some events were showing at different times, based on where they were displayed.
This led us to a deep dive into debugging to figure out what the issue was. The site uses two different time databases when calculating times and differences between zones and countries, and these were in conflict with each other. The second database is supplied by ICU (International Components for Unicode). ICU had been updated, and tzdata had not. What was even more confusing was that the time that appeared incorrect on the site was using the correct database, and the one that appeared at the correct time was using the incorrect database. We sorted out the issue and made sure all databases were correct, but then came the problem of how to update the individual events to reflect the expected time. While this could have been done with a script, there were too many variables to account for, including human editing by site admins that might have already addressed the issue manually.
In the end, we applied a technical fix, and still had clients double-check the times for fall events to ensure accuracy. With more and more provinces (and potentially the US) making similar changes, this provided some excellent experience for the future. We also learned that the sooner governments can announce such changes, the easier it will be for organizations to accommodate them.

