PST to EST is a 3-hour difference. EST = PST + 3. That's the simple version. The complicated version involves daylight saving time, and it has burned more people than any other seemingly simple calculation in distributed work.
The daylight saving trap
PST (Pacific Standard Time) is UTC-8. EST (Eastern Standard Time) is UTC-5. The difference is always 3 hours. But here's the catch: both regions observe daylight saving time, and they switch on the same dates (second Sunday of March, first Sunday of November in the US).
During daylight saving time, the Pacific zone uses PDT (UTC-7) and the Eastern zone uses EDT (UTC-4). The difference is still 3 hours. So within the continental US, the conversion is always +3 from Pacific to Eastern, regardless of DST.
The problem arises when you're converting between a US time zone and a location that doesn't observe DST (like Arizona, which stays on MST year-round) or observes it on different dates (like most of Europe, which switches on the last Sunday of March). During the two weeks between US and European DST transitions, what was a 9-hour difference becomes 8 hours. Miss this and you miss the meeting.
The real-world cost
I worked on a distributed team spanning San Francisco, New York, and London. Our daily standup was at 9:00 AM PST / 12:00 PM EST / 5:00 PM GMT. Twice a year, during the DST transition mismatch, someone would show up an hour early or late to the London meeting because they relied on their mental offset instead of checking.
In 2007, the US changed its DST dates (moving to the current second-Sunday-of-March / first-Sunday-of-November schedule). Enterprise calendar systems that hadn't been updated scheduled meetings at the wrong times for weeks. It was a minor Y2K for scheduling software.
ISO 8601 is the answer
If you're a developer, store and communicate times in ISO 8601 format with explicit UTC offsets: 2026-03-25T15:00:00-07:00. This is unambiguous. It doesn't matter if you call it PDT or PST or "California time." The -07:00 offset tells the receiving system exactly what moment in time you mean.
The worst format is "3 PM Pacific." Is that PST or PDT? Right now (March 2026) it's PDT, so it's UTC-7. But someone reading that string six months from now might calculate based on PST (UTC-8) and be off by an hour.
Common PST to EST conversions
For quick reference:
- 6:00 AM PST = 9:00 AM EST
- 8:00 AM PST = 11:00 AM EST
- 9:00 AM PST = 12:00 PM EST
- 12:00 PM PST = 3:00 PM EST
- 3:00 PM PST = 6:00 PM EST
- 5:00 PM PST = 8:00 PM EST
The practical implication for distributed teams: the overlapping business hours between Pacific and Eastern are roughly 9 AM to 2 PM Pacific (12 PM to 5 PM Eastern). That's a 5-hour window. Schedule important meetings in this window and you'll stop getting "can we move this earlier/later" requests.
I built a time zone converter at zovo.one/free-tools/pst-to-est that handles the DST transitions correctly and shows you the current time in both zones. Simple tool, but it prevents the kind of scheduling errors that waste everyone's time.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)