Booking platforms have been trying to deal with time zone limitations for their business for a long time. As a software engineer, I had to develop a solutions for a special edge case that’s easy to miss.
Here’s how I handled it.
What’s Wrong with Time Zones?
Time Zones aren’t always a homogeneous standard. There are a lot of variables to consider for each one besides location including political decisions, daylight saving time, and in particular the Greenwich divide.
We are capable of calculating the current time in different regions, but it’s not always as simple as it seems.
This user case might seem rather simple, but it involves a particular edge case.
Picture the following scenario: I’m currently in Japan on March 2, 2017 at 1:00 am and I need to book a flight for my significant other who is in the US. So I proceed to search with the following variables,
- March 1st 2017 – March 5th 2017
- From New York, NY to Phoenix, AZ
This would result in a “flight not found” response because March 1st has already past in Japan, where I am at. However, there’s a 13 hour difference between Japan and New York and in New York it is still March 1st.
How to Deal with Time Zones
In my case, the situation was similar to the one above and our engine failed to treat properly.
My approach to this situation was to calculate the day and time of the departure and arrival locations rather than the day and time of the person doing the booking.
- Request current time of the departure location
- Search for flights in that location that meet the day/time criteria
If your booking engine does not consider the Greenwich divide, then adjust the criteria to make it work properly.
If you are interested on knowing a bit more about this subject, I recommend watching this video (it’s fun to watch, i guarantee it).
Or you can contact me at [email protected].