It’s about time for another blog. It seems appropriate to actually put this on the web at the end of 13th b’ak’tun of the Mayan Long Count Calendar. World ending, alien invasion, mad cows notwithstanding, this is about time and the modern clock. I wanted to build a modern clock. Well somewhat modern, the display are a set of IN18 Nixie Tubes that I got last Christmas. After all, Okabe Rintaro noted that, “Nixie tubes, whoever made it has good taste.” I would agree, that should make for a nice clock.
What does concern me is the usability of the modern clock tends to suck. Given the basic mechanical watch which has been around for ages has a common simple interface. You could rotate the stem back and forth to power it and pull and rotate the stem to set the time. We could call “pop-corn” on the telephone and set the time to match the nice voice.
The modern clock has buttons, switches, knobs but nothing really ubiquitous other than flashing 12:00 when it isn’t set. What I think a modern clock should do is set itself and if it loses power reset itself within a few seconds. The rest of this blog is just getting to that.
UTC is French for Coordinated Universal Time and is available through network and radio. UTC can be converted to local time by the political geographical time zone offset and the time zone’s daylight savings time offset.
While time zone and daylight savings offset don’t change often, they are based on the political decisions and do change. In the US, daylight savings time start and end dates were changed by the 2004 energy bill. Many of the self setting clocks had the old date wired in and the change obsolete the clocks. Several GPS receivers also had the dates hard coded without the ability to correct the error.
Often confusion ensues and sometimes death with these changes.
Ideally Time Zones were longitudinal regions (24 or so spaced 15°) to replace apparent solar time. In reality, they follow an irregular shape based on the politics, wars, occupation, population and historical events. Many countries don’t follow the 1 hour timezone and use 1/2 hour increments.
Daylight savings time is usually associated with but not always based on time zone boundaries. For example, Arizona does not observe daylight savings time with the exception of Navajo Indian Reservations.
Getting UTC isn’t too hard but timezone and daylight savings time require access to an up to date database and location. The location is critical if close to a boundary between two timezones. For example, radio transmission from either side could be received with differing timezones.
In the United States, a low frequency (60KHz) transmitter WWVB or the high frequency counterpart (10MHz) WWV located at Fort Collins, Colorado broadcast UTC and daylight savings transition information. The “atomic” clocks set time using a WWVB receiver and decoder. They usually only receive time at night and it may take a few days for them to set their time. Also some of the clocks had the daylight savings dates hardwired rather than use the transition data. I have many of these clocks and the time setting capabilities leave a lot to be desired.
GPS satellites have NMEA (National Marine Electronics Association) messages with UTC time and location of the receiver. Given the cross many timezones, it isn’t practical for that information.
FM broadcast transmitters use RDS/RBDS (radio data system/radio broadcast data system) to broadcast time, station identification and program information on a 57KHz subcarrier. They broadcast UTC, modified julian date and local time zone offset.
Time can be set by the internet. The NTP (Network Time Protocol) returns UTC time and uses their timezone database for local time.
For example, Google has an API for timezone based on longitude latitude coordinates. The concern I have is will they be around in five years. I would be happier if there was a “pool” of timezone servers similar to the ntp pool. That is rather than a single company providing this service, it could be provided by multiple companies or individuals. I don’t mean to pick on Google, but they have dropped a number of projects which is pretty normal for a company, but who is to say this API from Google will be around and supported for the next 5 years. If this was managed by an international organization like ICANN and had involvement from multiple companies then the longevity might be seen to last a lot longer.
I have an eighty year old watch that can still keep time, I have lots of modern clocks, cell phones that don’t last much past two years. Electronics has been progressing at such a rate that we have gotten used to 18 month obsolescence. I’d really like this clock to last longer than that.
Computers use a time zone database where a user can pick a city which is in the same time zone. While I don’t live far from Vancouver, BC., my time zone is safest set to Los Angeles, CA. (or Cupertino, CA for Apple products) For Microsoft products, my timezone is defined as Pacific Time and lump Canada and US together. This will work as long as Canada and the US agree to a common time zones.
The Olson time zone data base is a maintained open source database used by Java, Linux, Solaris and other operating systems. http://en.wikipedia.org/wiki/Tz_database
It was founded by Arthur David Olson and contains a rich history of the politics of changes in local times zones. Based on rules, the database is compiled by the zone information compiler (zic) to produce a set of binary files by geographic location. In 2011 an astrology company sued Mr Olson and the database was turned over to ICANN who will take care of the legal issues (http://www.iana.org/time-zones) The suit has since been dropped.
One existing distribution method of time zone information was RFC4833. This describes DHCP option codes for sending the POSIX IEEE1003.1 time zone string which a DHCP address assignment is made. This doesn’t appear to be supported in any of the home routers that I’ve looked at and it doesn’t show up as a named DHCP option for Linux. One problem I see with this is my DHCP information may not come from the same state that I’m in.
So far the candidate I am going to explore is the FM broadcast RDS/RBDS using one of the Silicon Labs FM receivers.