Here at AllyO, we connect candidates with hiring managers for interviews across the country. A problem of time zones naturally arises for these hiring managers. For example, a candidate may apply with Ally for a job in Denver whereas another will apply for the same job in San Francisco, while the the hiring manager responsible for interviewing for both roles is residing in New York.
As we solve for this problem, we are diligent about the fact that we assist thousands of recruiters, where each recruiter has the possibility of 7 to 10 interviews a day across multiple time zones. Here’s how we solved multi-timezone interviewing scheduling for thousands of recruiters and candidates.
We could hypothetically use one entry in our database for each interviewer availability. So for example, if an interviewer is available on every Monday at 2pm, we could create 53 entries into our database, each representing the Monday of every week for the entire calendar year. But this could easily grow exponentially into millions of records!
Instead, we create a column in the table that represents a day and a time (eg: 2pm on Monday), instead of a datetime slot (eg: 2pm on April 24). Using this method an interviewer can tell Ally that they are available every Monday at 2pm, and instead of creating 53 entries into our database, and create just 1 that includes every Monday of the year!
Here at AllyO, we often deal with interviewers and job openings that could belong to any timezone within United States and globally. It became evident that we need to solve for a consistent behavior that is easy to understand in our system. Developer’s don’t want to spend multiple hours figuring through time zone differences for each interviewer.
The following is our solution: For every interviewer, job requisition, and anything related to datetime, we convert it to UTC first, and then enter it into our database. All calculations and processing is now done in UTC. When the datetime is about to be sent out of our system to the user, then we make the conversion to the user’s time zone.
Back to our one entry in the database of Monday 2pm. Given that we have one entry that simply says Monday 2pm, this brings in the confusion of daylight savings. Say for example, the entry was made in June for an interviewer that lives in California. So this becomes 9pm in UTC, but if this was done during December, this becomes 8pm in UTC due to daylight savings changes in November.
The bug occurs when we retrieve this time. We don’t know if we we should subtract 7 hours, or 6 hours. To counter this bug, we always convert the entry into summer first and then convert it to UTC. So in this specific example, whether the entry was made in June, or December the database entry would be 9pm. This way during retrieval, the system knows to always subtract 7 hours, and will translate to 2pm in PT.
The following is a snippet that checks if we are currently under daylight savings:
In python when you create a datetime, it automatically assumes a naive datetime. What this means is that you cannot convert this datetime into any timezone, because it doesn’t have an origin timezone to begin with. The developer needs to explicitly specify what timezone does the given datetime fall under. Once this is specified, then the conversion to different time zones can be done as needed.
The following snippet does translation between different timezones:
Stay up-to-date with the latest insights and trends from AI recruiting brought to you by AllyO Blog!