Days since the last time zone error: -1
Sooner or later every product scales from one time zone to several. Introducing various timings is vital to make the product more flexible for users from all corners of the planet. It is also a great functionality to make your team crack their brains.
When I stumbled upon time zones testing for the first time, there was not much information about how to do it best (read to create a time travel machine). That’s why I decided to share my experience and algorithm with fellow testers who’ll need it someday.
So, take your notebooks and write down the answers to these questions first:
1. What time zone is the server of your product using?
2. Which places of the app will be affected by the time zone's appearance? It may be various reports, dashboards, notifications, etc.
3. In what format are dates stored in the database?
4. Depending on which time zone does the data go into the database? For example, for the time of creating a user.
5. Which time zone does the target market use?
Time zone test cases
When you find a little bit more information about the app, you can proceed to test cases.
The first subject to test is settings/profile, where usually the time zone field is added. The scheme below shows what you should consider while testing this subject.
Let’s move on to more specific things. At the analysis stage, we have already found out which sections are affected when adding time zones, and based on this, we should continue our testing.
Consider the following frequently encountered sections of the application, which may be influenced by time zones:
- Graphs, Reports or Dashboards
- Integrations
- SMS or Email notifications
- Correspondence
Graphs, Reports and Dashboards
Usually, some units of the project are displayed here — for example: users, transactions, services, etc. And at this stage, we need to know how long the information about the date is stored in the database and the calculations are being made.
There are three possible options: relative to the user, relative to the server and relative to UTC+0.
In the second and third cases, there is usually an additional field stored — the time zone of the user. Let’s look at each option closer:
Time relative to the user
In fact, this is the most unlikely and unreliable way to store a date. Such storage can lead to numerous defects.
One example: the data is used by different users with different time zones -> there will be confusion with the display.
Or, let's say the user decides to change their time zone -> additional logic is needed to change the time for all entities, or, again, there will be confusion with the display.
This option requires more logic to support and, as a rule, is not used when developing applications with users in different time zones.
Time relative to the server
This option of using time is normal for calculations (for example, the number of transactions per day). But this case also increases the likelihood of bugs. For example, according to the server time it is already 00:00, and the client has 23:00. Accordingly, the client’s charts may go astray and it will display, for example, February 28th, although the user still has the 27th, or transactions made on the 27th between 23:00 and 00:00 will be counted the next day.
Time relative to UTC + 0, and the time zone is recorded in a separate field
And thus, when calculating or displaying data on the UI, we rely on the user's time zone. This is the most reliable option. An example of how this looks is shown in the diagram below:
Bonus tip
Please note that when testing applications for the US/Canadian market, there is a significant difference: European time zones are in UTC+X, while users most likely have UTC-X. And, if you test the application in UTC+X, you can miss some bugs, or vice versa, find some specific ones for positive time zones (these will be low-priority bugs since they are unlikely for real clients).
From this follows a recommendation — immediately use a VPN during testing or set the time relative to the target audience.
Boundary value analysis technique for time zones
Remember the boundary value analysis technique? Its finest hour has finally come! When testing time zones, it can be used to its fullest, since most of the problems are hidden in the transitions between days/months/years.
Let's take a look at the time zone check with the following example: imagine we have a graph that displays the number of users who visited the application for each month of the year. And today is March 1st. What cases should be considered and what is important to remember?
1. Make sure that the charts are calculated relative to the time zone set in the user account. If the calculation logic is still different and cannot be changed, take into account that this can lead to additional defects and pay more attention to boundary values (in particular, the time 23:00 - 1:00).
2. For February only ask yourself: are all users counted exactly from February 1 00:00 to February 28/29 23:59?
3. Did March appear on the chart on March 1 at 00:00 relative to the time zone in the account?
4. If the user visited the application on March 1 between 00:00-01:00, will it be displayed as March? And if on February 28 between 23:00 - 00:00 – will it be considered in February?
5. What happens to the data if we change the time zone to one where March has not yet arrived?
6. And what happens if we change the time zone from a place where it is still February 28, to a time zone, where it is already March 1?
7. Suppose we still have a time machine and today is the last Sunday in March. The day when the change from winter to summer time goes on. How will the data display change? Will there be errors in the calculations? In general, this case is worth checking in the whole application where there is a time display.
Please note that if we are testing a report that the user can download to their device, it is worth considering how long the report takes to generate.
Data from integrations
Here consider the following questions:
1. Do we collect data with both date and time? In what time zone is the data given to us?
2. Is it possible for us to process the data on our side and bring the date to a certain format before writing it to the database?
For example, we write in one of the following forms: DD:MM:YYYY 00:00 UTC+0 // DD:MM:YYYY // DD:MM:YYYY 00:00 UTC-5, etc.
By answering the questions above, we can proceed to the testing to check the following:
1. Do we display data in the same date and time formats as in the third-party integration?
2. What happens if we download this data in CSV (if such functionality is available in the application)?
Example from my experience
The third-party integration stores transactions with a date field (both the date and time are displayed there relative to the user's time zone). And the API of this product is designed so that our application can pick up these transactions only with a date but without a time.
Accordingly, the time 00:00 was additionally entered into the database. Because of this, the following bug occurred: transactions for some time zones had a date a day earlier than it was displayed on the integration side. The solution was to put down the time 12:00 instead of 00:00.
SMS/Email notifications
For this case answer the following questions:
1. Are notifications sent based on the user's time zone?
2. What happens if the user changes the time zone? Do we take into account the fact that the user may receive 2 notifications when changing the time zone, or may receive none at all?
3. Let's say that these are notifications about a new transaction/user/etc. Does the message show the date relative to the user's time zone or as recorded in the database?
Correspondence
In this case, we need to check whether the time zone has changed and whether there is a correspondence for the next day today.
Bottom line
On this note, my story about testing time zones ends. I recommend thinking through test scenarios and preparing test data when checking time zones, as well as drawing graphs. Thus, at first glance, confusing and complex functionality will become easier to understand.
I wish you good luck and a non-boiling brain!
.svg)
