Time. It seems so straightforward, doesn’t it? You glance at your watch or phone, and there it is. But in the world of web applications, asking “what time is it now?” can quickly become a surprisingly complex question, especially when dealing with users across different geographical locations.
For those of us building web applications, particularly platforms like Workforce.com which are deeply rooted in time tracking, the nuances of time zones are not just a minor detail – they are fundamental to the user experience and data integrity. Accidentally displaying times in the wrong time zone isn’t just a minor UI glitch; it can lead to significant confusion and operational errors.
One common pitfall is time zone leakage. While techniques like Sam’s method can be effective when all rendering happens client-side in JavaScript, they fall short when server-side rendering comes into play. Think about generating reports in HAML/erb, exporting data to CSV files, or scheduling email notifications via background jobs. These server-side processes need to be acutely aware of time zones.
Our approach at Workforce.com involves a multi-layered strategy to ensure accurate time representation across our platform. Firstly, we store a time_zone column for each user in our database. Secondly, all actual timestamps are stored in our PostgreSQL database as timestamp without time zone, effectively storing them in UTC under the hood. This standardization is crucial.
To manage the context of time zones within our application, we utilize an around_action in our controllers. This automatically sets Time.zone for each request based on the current user’s profile. For background jobs, we employ TimeZone.in(@user) {} to wrap the job execution within the correct user’s time zone. To further enforce this practice and minimize human error, we are exploring the implementation of linters that will automatically detect and flag any code that might neglect time zone considerations in background jobs.
However, the real challenge arises when you need to display time information for one user (User B) to another user (User A), and they are in different time zones. Imagine User A, based on the West Coast, managing a factory on the East Coast. They need to see the accurate start time of User B, who works at that East Coast factory. Simply rendering the time in User A’s time zone would be incorrect and misleading. While rendering it in User B’s time zone would be accurate for User B’s context, what happens when we need to display data for User C, who is in Central Time, within the same view?
This complexity pushed us to evolve beyond a simple per-request time zone setting. We are transitioning towards a model where our application models themselves become time zone aware. Now, when we retrieve any object containing time-related columns, our system dynamically determines the appropriate time zone for display. This determination is based on relevant associations defined on the object, typically linked to the user or their location. For instance, when displaying User B’s start time, the system recognizes the association to User B and displays the time in User B’s designated time zone, regardless of User A’s time zone.
Our current implementation of this time-zone aware model approach is detailed in this code snippet: https://gist.github.com/ghiculescu/d8148f60a4e8c8b0fa7ceb77df49b139. This approach allows for a more robust and contextually accurate handling of time across our application, ensuring that when a user asks “what time is it now?” in the context of our platform, the answer is always relevant and precise, no matter where they or the data they are viewing are located. Effective time zone management is not just about technical correctness; it’s about building applications that are intuitive, reliable, and truly global in their reach.
