I recently received an email invitation to attend a webinar.
According to the message, the online event was going to be held (on March 9) at 18:00 GMT.
Within both the registration page and the confirmation message, the time was displayed as 19:00 CET, though.
I have to admit I needed to check for the equivalence…
Now, you may say it’s correct: 18:00 GMT is the same as 19:00 CET (at least at the beginning of March in the Northern hemisphere).
And it’s true: it’s correct.
Yet, it might be confusing, especially if you consider that the target audience for this event, which is based in Spain, would have likely expected the GMT+1 representation to be used.
That’s exactly the kind of testing some people/organizations skip the most or too often miss.
So, you might have a feature which is correct on its own.
And another one which is correct too, at least if you look at it alone.
Yet, when you put the two together, something which may represent a problem —an inconsistency, for example— arises.
And when things start being confusing, they usually stop being correct.
To make things worse, after letting the organizer of the event know about the potential problem represented by the inconsistent time notations, it turned out the time was not correct at all: it must have been 18:00 GMT+1 (or 18:00 CET).
Well, once the issue was fixed, the information included in the following reminders was correct at least.
However, since nobody challenged the assumption that the attendees would have been happy to be reminded for ten minutes that the event would have begun shortly and that they were in listen-only mode, the webinar eventually started late. Which was just the cherry on the top…
#ThisIsASeriousLackOfTestingMindset
P.S. Speaking of confusion, you may have a look at the following video about time zones, daylight saving time and other painful topics which make life especially fun for software professionals. Enjoy!
https://www.youtube.com/watch?v=-5wpm-gesOY
