Timezone Markers Explained

23 Mar 2021

This page attempts to clear up some ambiguity regarding timezone selection for the Precision Clock Kit.

The clock can be configured for pretty much any location, and will automatically handle Daylight Saving Time (DST). However, because of the complexity and subtle nuances involved with timezones, it would not be sufficient to simply have jumpers or switches on the back to select one.

Currently, to change location, a different firmware image must be flashed to the chip.

There are two lights in the middle of the clock which display the timezone abbreviations for winter and summer time. When a clock kit is ordered, I laser-etch the part to match the chosen location.

UTC

As of November 2020, all clock kits support UTC, regardless of timezone.

A pin can be shorted to ground, which will override the display with UTC. This can either be wired up to a switch, or simply a pin jumper. There are instructions to do this on the assembly instructions page.

If you only want the clock to display UTC, that is fine also. Many people have asked for this. In that case, I normally etch the summer-time marker to display "UTC+1". This is purely to remind (or warn) people about not fitting the DST-enable jumper.

If a location has no DST at all, I can etch one marker for the local time and the other to say UTC. The code can be configured to light those up correctly. For areas with DST, if you enable UTC mode by shorting the pin on the back, it will turn off both lights.

The Olson TZ database

There is no global authority on timezones, no international standards, each government makes up their own rules. The closest thing we have to a reference is the olson tz database, which is used by nearly everyone, and even it comes with warnings about inaccuracies.

Whenever there are ambiguities, I turn to the tz database for answers. However, the logic for the precision clock kit was written entirely from scratch.

In the database, each location gets an abbreviation for the time in summer and winter. For instance, Los Angeles uses Pacific Time, and so the clock is etched with PST and PDT, for Pacific Standard Time and Pacific Daylight Time. But remember, not all areas in Pacific Time have daylight saving time, and PST/PDT on its own is not enough to describe the timezone.

GMT, BST and UTC

Greenwich Mean Time (GMT) has been a source of great ambiguity because it has so much history and has meant different things over the years. People often use GMT and UTC synonymously, which further clouds the issue.

I am not an expert on this, I am simply following the decisions made by the people who maintain the tz database.

• UTC is universal coordinated time. It is the same everywhere, no matter where you are in the world. All other timezones are defined by their offset relative to UTC.

• GMT is the name of the timezone for Great Britain during winter time. No more, no less. In summer, the timezone for Great Britain is BST, British Summer Time.

The laser-etched indicator for the Precision Clock in Britain displays GMT and BST.

Some people saw this and understandably thought that it referred to "GMT" and "Local Time". This is not true. On all of the clocks, the top marker is winter time and the bottom marker is summer time. It just so happens that in Britain, GMT is the abbreviation for winter time.

The use of "GMT offset" by several legacy systems throws further confusion onto the ordeal, but following the tz database, I only use GMT to refer to the local time, during winter, in Britain.

Daylight saving rules

The DST rules are different on different continents. This is an immensely complex subject which I won't go into fully, but let me just say this: The timezone database has over 500 different entries, each indexed by the name of a major city. Although I print the three- or four-letter abbreviations on the clock, such as "EST" for eastern standard time, those are not sufficient to describe the timezone rules. The only way of accurately conveying the timezone is to name a physical location.

The DST rules for North America and for Europe are similar, but not quite the same. In Europe, DST begins on the last Sunday of March at 1AM UTC. In America, DST begins on the second Sunday of March, at 2AM local time (so Eastern time switches an hour before Central time, and so on). So, for just one hour each year, clocks in Chicago read the same as clocks in New York.

In Australia and New Zealand, DST is in effect during Christmas and New year. And the switchovers happen at 2AM or 3AM local time, sometimes on the first of the month, which means that in some cases, the UTC month reads differently to the local time month during the switchover.

The number of subtle and strange rules is almost endless, and the clock kit supports nearly all of them. About the only locations not fully supported are some Arabic countries which interrupt DST for Ramadan, and Lord Howe Island off the coast of Australia, which shifts the clocks by half an hour throughout summer.

I promise that the next version of the clock, when I finally build it, will support these edge cases.

UT1, and taking GMT literally

Some people argue to eliminate the use of GMT entirely, as it is ambiguous. If you really mean the Mean Solar Time at the Greenwich meridian, then GMT would not be exactly equal to UTC.

The problem with Mean Solar Time of anything is that the days are not all the same length. The earth wobbles and is very imprecise for timekeeping. If you go by mean solar time, even the length of a second is not consistent from one second to the next. Useless!

The mean solar time at the Greenwich meridian is referred to as UT1. UT1 and UTC are always within a fraction of a second of each other. To make sure they don't drift too far apart, leap seconds are periodically added to UTC. The benefit of using UTC is that each second is exactly the same length, thank god, and all we have to worry about is that some days have more seconds than others.

Some people argue to abolish leap seconds – they do cause a lot of havoc – but what they are arguing is that nobody cares if UTC aligns with the meridian at Greenwich. They are not arguing against having a consistent length of second. And besides, it would take hundreds of years for the drift to become noticeable by normal people.

Now for the tricky part. Some people argue that GMT is equal to UT1, which it no longer is. GMT is now equal to UTC. The standards bodies in the UK are all very touchy about this, and try to avoid the subject by never ever mentioning GMT, but the government still says that the timezone in the UK in winter is GMT, and everyone sets their clocks to UTC. This has to be the case, because the BBC, NPL and every other authority broadcasts the time with leap seconds.

UT1 does not have leap seconds – it simply wouldn't make sense.

NPL (who manage the 60kHz broadcast for radio controlled clocks in the UK) do in fact broadcast both UTC and UT1 as part of the signal, but all radio controlled clocks that I've seen display UTC.

About the only sensible way to clear up the ambiguity is to rename winter time in the UK. Following the logic of the rest of Europe, where Central European Time is CET/CEST, and Eastern European Time is EET/EEST, Western Europe should be WET/WEST. I believe some countries in North Africa do in fact use these abbreviations, but no one is ever going to use them here, for the one reason that Wet and West are both English words. If you're trying to reduce ambiguity, this isn't going to help!

But there's more...

If you find all this stuff interesting, I strongly recommend reading through the olson tz database. Despite what it sounds like, the database is more prose than data, and is hugely informative, with long histories and fascinating details that are endlessly debated. For easy reading, the whole thing is mirrored on github. Take a look at the file named europe for an entertaining read.

With the Precision Clock Kit I never originally planned to support other timezones, and ended up recreating most of the tz database from scratch. Only this time, the entire system is implemented in assembly, and does all of the logic using BCD arithmetic. The different timezone and daylight savings rules are generated using the assembly macro preprocessor, a makefile template, some javascript and a little bit of perl. Sometimes I find myself astonished that it works at all. But it does, and hundreds of people have built clocks that use this code.

If you want to dig deeper, take a look at the source code for the precision clock on my github page.