457: Time Zones with Sally Hall

What It Covers

Sally Hall and Joelle Kenville explore time zone complexity in software development, covering daylight savings bugs, scheduling systems, time-of-day calculations, database optimization strategies, and why developers should never write custom time math.

Key Questions Answered

• •Test Strategy for Time Zones: Write tests using time zones different from your local environment and CI server (like Chicago time when working in Eastern) to catch time zone bugs locally before deployment, preventing false positives from matching environments.
• •Database Performance for Scheduling: Postgres materialized views with 8 million time slots refresh faster than Ruby calculations that took 45 minutes. Use database-level time math with debounced refresh jobs limited to one concurrent execution for appointment scheduling systems.
• •Time Object Math Rules: Never manually add offset hours to Ruby time objects—the Unix timestamp already handles conversions automatically. Adding offsets creates incorrect times because you're shifting the underlying timestamp when no math is needed, only metadata changes.
• •Display Strategy for Multi-Timezone Apps: Always show time zone abbreviations next to timestamps (like 9:00 AM EST) when users and service providers operate across different time zones, preventing confusion about whether times reflect user or provider location.