Fixing Bugs and Building Tests - Second Contribution to GNOME Calendar

Introduction

After learning the basics of the GNOME calendar contribution workflow and making our first contribution, Otávio Silva and I saw a blog post by Jeff Fortin (one of the project's maintainers) calling people to help expand the calendar's test coverage. The blog post caught our attention as tests are an extremely important part of any software and it seemed like an impactful contribution that we could make.

We saw firsthand the impact of tests when we worked on Kernel-workflow, an open-source project that started at USP, to help reduce the overhead when contributing to the Linux Kernel. When we wrote our contribution to this project, automatic tests helped ensure that our code didn't affect the behavior of other parts of the code and helped us make sure that our code did what it was supposed to.

GNOME Calendar, however, has very limited test coverage. As Jeff himself put it in his blog post, "There currently are some unit tests in GNOME Calendar, but not nearly enough (...). (...) Before we start fixing those bugs, we need as many unit tests as possible to cover spec compliance." He also pointed out that timezone-related issues are a key aspect of the project that needs more testing.

After our first contribution, Jeff contacted us and pointed us to an issue where we could fix a bug and write a unit test to prevent something similar from happening again.

The Bug: Incorrectly Interpreting Floating Time Events

One of the key features of a calendar app is to be able to import and export events. This allows integration and portability between different software. In order to make this easier, apps such as Google Calendar, Samsung Calendar, and others follow a standard created by the IETF (Internet Engineering Task Force). This standard is called RFC5545 and specifies rules to make different apps compatible with each other. This document "defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol."

One of the rules established by RFC5545 has to do with events that should happen at a specific time, regardless of the timezone - these are called floating time events. If a floating time event is scheduled at 15:00, it means that it should happen at 15:00 in whatever timezone the user is in. That behavior, however, was not correctly implemented in GNOME Calendar when it imported an event from an iCalendar file. GNOME Calendar treated floating time events as happening at the UTC timezone. Therefore, a floating time event scheduled for 15:00 would be displayed at 12:00 in São Paulo, Brazil, and at 16:00 in Canada.

The Bugfix: Interpreting Floating Time Events in the Local Timezone

The solution for this bug was rather simple and someone had already proposed it in the issue's discussion on GitLab, but no one had implemented it. What we did was simply change the timezone of an imported event from 'UTC' to 'local'. That fixed the bug! What we wanted to do now was create a test to assess if events were being created in the correct timezone. That would be useful for this bug specifically, but it could also help spot other similar bugs.

Writing a Unit Test

To create the test and check if the events were being created in the correct timezones, we created a series of mock events in different timezones (with UTC, UTC+X, and UTC-X), and some floating time events. This way, we could create a test that would work for the bug we had just fixed but would also work for events that were not 'floating time' and had different timezones. Then, we wrote tests to check if after these events were imported, their timezones were the ones expected.

Conclusion

Our bugfix and the test that followed were accepted and merged into the project! Our next project was another bugfix, but this time we faced a challenge in creating a test, that we still haven't solved. More on that soon!