Understanding Time Zones When You Actually Need to Coordinate Across Them
PDT — Pacific Daylight Time — is UTC-7. It runs from roughly the second Sunday in March through the first Sunday in November. The rest of the year you're on PST, which is UTC-8. That's the whole thing. The reason this matters isn't because PDT itself is complex, it's because almost everything digital that touches global users has to deal with time zone transitions, and most of those deals go wrong in predictable ways. When I was building a notification system for a SaaS product with users across three continents, I ran into a specific edge case that cost us about two weeks of debugging. The issue was daylight saving transitions. Our server was in us-east-1, our database stored everything in UTC, but the frontend rendered local time using browser JavaScript. The problem: DST doesn't happen on the same date everywhere, and some years the US transition happened on a different date than Europe. On the day of the spring-forward transition, users in LA would see their scheduled notification time shift by an hour relative to users in London, even though the UTC timestamps were identical. The fix was straightforward but required changing how we thought about the problem. Instead of computing local display times server-side or relying on client-side conversions, I moved all scheduling calculations to UTC and used a library like `dayjs` with explicit timezone data. More importantly, I added a warning UI element that triggered whenever a user's scheduled event was within 24 hours of a DST transition in their region. The library call looked something like checking `Intl.DateTimeFormat.resolvedOptions().timeZone` to confirm what the browser thought the user's zone was, then cross-referencing against known transition dates from the IANA database. This cut false notification mismatches from about 12% of spring-transition days down to near zero.
How to Work With PDT Without Losing Your Mind
Store everything in UTC. This is the single most important rule and the one most teams violate. I've seen codebases where timestamps were stored in local time because "it felt more intuitive for the team." Intuitive for whom, exactly, when the team spanned four time zones and someone in New York had to debug a production incident at 2 AM Pacific time? Never store local time in the database. Use `TIMESTAMPTZ` in PostgreSQL, `DATETIME` with explicit UTC handling in MySQL, and when you pull values out, convert at the presentation layer, not the storage layer. If you're writing a Node.js application, stop using `Date.prototype.toLocaleTimeString()` without explicit timezone arguments. The default behavior relies on the server's locale setting, which is usually UTC in containerized environments, meaning your timestamps will display incorrectly to users in Pacific time. Instead, use something like:
const time = new Intl.DateTimeFormat('en-US', {
timeZone: 'America/Los_Angeles',
hour: 'numeric',
minute: '2-digit',
hour12: true
}).format(new Date());This produces output in PDT during summer months and PST during winter. The timezone identifier `America/Los_Angeles` automatically handles DST transitions using the IANA database, so you don't have to hardcode any transition dates. This has saved me from having to manually update deployment scripts twice a year. The first trap is assuming that a fixed offset like UTC-7 applies year-round to Pacific time. It doesn't. If you're doing any calculation that involves adding or subtracting hours based on "PDT being seven hours behind UTC," your code will break every March and November. Always use named timezones, never fixed offsets, for anything that needs to persist across DST changes. The second trap is more subtle and involves scheduling. Let's say you want to send an email at 9 AM PDT every Monday. If you store the cron job as "UTC-7, 9:00," the recipient will get the email at 9 AM Pacific during spring and fall, but at 8 AM Pacific during the two-week gap between the US and Canada starting DST and Europe starting theirs — or vice versa in the fall. The email lands at a different local time for about a week each transition period. For transactional notifications this is usually fine, but for scheduled reminders or billing cycles it can cause confusion. The workaround is to store the intent ("9 AM Pacific") as a timezone-aware schedule and let the scheduler resolve it against the current UTC offset at execution time, rather than precomputing the UTC timestamp.
Get the Full Details
A third issue I've encountered involves testing. Unit tests that assert against specific timestamps are fragile when timezone logic is involved. I learned this the hard way when a test suite passed locally but failed in CI because the CI runner was in a different timezone than my development machine. The assertion `expect(date.format('z')).toBe('PDT')` would pass in March but fail in January. The solution was to make timezone assertions relative — check that the UTC offset is either -7 or -8 depending on the date, rather than asserting a specific abbreviation. Timezone abbreviations are unreliable; UTC offsets are not.
What to Use and What to Avoid
In JavaScript, use `Intl.DateTimeFormat` for display and `luxon` or `dayjs` with timezone plugins for manipulation. Avoid `moment-timezone` for new projects — it's feature-complete but the bundle size and maintenance trajectory make it a poor choice going forward. In Python, use `zoneinfo` (built into 3.9+) instead of `pytz`. The `pytz` documentation literally warns against using it for new code, and the migration path from `pytz` to `zoneinfo` is mechanical — replace `pytz.timezone('America/Los_Angeles')` with `zoneinfo.ZoneInfo('America/Los_Angeles')` and everything else mostly works. For databases, PostgreSQL's `timestamptz` type is genuinely good. It stores in UTC internally and converts on output based on the session's `timezone` setting. Set your connection string to use UTC, and you're mostly set. MySQL's `DATETIME` type is the problem child here — it has no timezone awareness baked in, which is why so many MySQL applications store timestamps as Unix epoch integers or strings with explicit UTC suffixes. If you're on MySQL and doing heavy timezone work, consider switching to `TIMESTAMP` columns, which do convert to the session timezone on read and write, though this behavior is deprecated in MySQL 8.0 and removed in future versions. Plan your migration.
When PDT Logic Fails Completely
There are edge cases where timezone libraries simply cannot help you. The most notable is Samoa, which skipped an entire day in 2011 when it jumped from UTC-11 to UTC+13 by moving the international date line. Any library that relies on historical timezone data available before 2011 will get this wrong. Similarly, Iraq briefly observed UTC+3 in 2022, a change that some older IANA database versions don't reflect. If your application needs to handle scheduling in regions with recent or irregular timezone changes, you should verify your timezone database version regularly and consider pinning it to a known-good release rather than letting it auto-update. Another scenario where timezone logic breaks down is when users manually override their device timezone. A user traveling from Los Angeles to Tokyo might keep their phone on PDT for convenience, which means any app relying solely on device timezone will schedule notifications at the wrong local time. The mitigation is to use IP-based geolocation as a fallback when device timezone seems inconsistent with other signals, though this introduces its own accuracy issues and privacy considerations.
Practical Checklist for Your Next Deployment
Before pushing changes that touch time handling, verify the following. First, confirm that your application server's system timezone is set to UTC — check with `timedatectl` on Linux or the system settings on macOS. Second, audit your database queries for any hardcoded timezone offsets or local-time string parsing. Third, run your test suite with the `TZ` environment variable set to different zones to catch locale-dependent failures. Fourth, add a cron job or scheduled task that logs the current PDT offset once per day so you can detect unexpected changes — I learned about a server config drift that shifted our offset by an hour this way, and the only symptom was users complaining that their morning alerts were arriving an hour late. Finally, document your timezone assumptions in the code. A comment saying "times stored in UTC, displayed in America/Los_Angeles" is worth more than a hundred lines of implicit behavior. When the next developer on your team inherits a bug at 3 AM their time, they'll appreciate knowing exactly what the baseline assumption was.
