There are around five million residents in the Canadian province of British Columbia. Most of the population is condensed into the southwestern corner close to the city of Vancouver and the border with Washington State. Vancouver uses the Pacific time zone, but the province has almost a million square kilometres and is so big that other areas use different time zones. How many time zones are there in British Columbia?

The short answer is three:

  1. Southwestern parts like Vancouver, Vancouver Island, and the Lower Mainland use Pacific time, which is GMT -8 hours in the winter and GMT -7 seven hours in the summer.
  2. Southeastern parts like Cranbrook, Golden, an Invermere use Mountain Time, which is GMT -7 in the winter and GMT -6 hours in the summer. Except for Creston, which does not observe daylight savings time.
  3. Northeastern parts like Fort St. John, Peace River, and Fort Nelson use Mountain Standard time, which is GMT -7 hours year-round. Except for Fort Ware, which uses Pacific time and observes daylight savings.

But if you work in the software industry, you probably also need to think about a fourth: Coordinated Universal Time (UTC). Many servers and infrastructure systems use that instead of local time zones.

There’s a great summary at TimeAndDate.com. To wrap my head around it, I made this map:

Heads-up: This will change if and when daylight savings is eliminated in BC and North America.

For now, I created this custom BC time dashboard on TimeAndDate.com. This is how BC times look in the summer of 2022 (daylight savings time). Notice that Golden, Cranbrook, and Invermere are one hour ahead of the rest of the province:

This screenshot show how it looks after daylight savings ends (02:00 on 2022-11-06):

Even if your project is set up perfectly today, entropy will creep in. Each code change, external integration, and database schema or update query that touches a date or time adds a new risk of introducing a time zone defect. If your project uses one time zone for simplicity, you should still look for time zone issues because your users, third-party integrations, database administrators, or logging and reporting systems all have their own ideas about time.

It sounds like it will get more complicated for technical staff when daylight savings time is eliminated, because then we’ll have to support all the current time zone rules we’ve been working with for decades (for historical records), plus a set of new rules to eliminate daylight savings.