About time…
We have lots of ways to describe distance: feet, furlongs, meters. You can measure volume in liters, quarts or cubic miles. We weigh things in stone, pounds and kilograms. Same is true for geometric angles, acceleration, power, torque and so on.
It struck me a while ago that that’s not true for time. If you’re looking to measure fine-grained intervals, the only common fundamental unit is the second.
You might argue that there are lots of calendars that break up the year differently — Aztec, traditional Chinese, Hebrew.¹ But calendars are for managing time in weeks, months and years. They tell us when to celebrate feast days, expect solar eclipses and replace our smoke detector batteries.
Seconds, minutes and hours, by contrast, are for clocks. They measure sub-day intervals. They tell us when to wake up, how long we have for lunch and whether the teenager has broken curfew. Everybody everywhere uses a 24-hour hh:mm:ss clock for that. There’s just no alternative.
That seemed weird to me. I dug in a little bit.
A brief detour to Babylon
Clocks are sexagesimal—they’re based on the number sixty. Sixty’s a handy number, because it’s divisible by lots of numbers: 2, 3, 4, 5, 6, 10, 12, 15, 20 and 30. (In fact, sixty is divisible by more numbers than any number lower than it, which means it’s a highly composite number). There are sixty seconds in a minute and sixty minutes in an hour.
The names “minute” and “second” come from Latin. The phrase “pars minuta prima” means “first small division” (of the hour), and we get “minute” from it. “Pars minuta seconda” means “second small division,” and is where we get “second.”
We inherited our system of time from the ancient Babylonians². They used sexagesimal measurements for arcs on a circle, as well.
Our habit of breaking the day into 24 hours is also Babylonian. You probably count from one to ten on your fingers, but the Babylonians used a duodecimal — base 12 — numbering system because they could count to 12 on one hand, and 24 on two.
This picture explains how to count like a Babylonian:
If you want to count from one to twelve, you touch the tip of your thumb first to the top of your index finger, then to the second segment of that finger, then to the third, then to the tip of your middle finger, and so on. Since Babylonians were in the habit of counting to 12 or 24 on their fingers, it makes sense that they’d split days into that many hours.
Base 10
Except for clocks and angles, we’ve abandoned the duodecimal and sexagesimal systems that the Babylonians used. We use base 10, or decimal, systems, these days.
The fact that we still keep track of time using the old bases means that doing math on time is hard for us. There are 60 minutes in an hour and 86,400 seconds in a day. It’s tough to do division in your head with numbers like that. That’s the same problem with inches (12 of them per foot) and ounces (16 of them per pint). They’re archaic measuring systems, and you can’t easily multiply and divide to convert among different quantities on the same scale.
Metric measurement systems use base 10. It’s a lot easier to convert quantities and do math in your head in metric. It’s way easier for us to divide by 10 than by 24. That’s why most sensible (or sensibly lazy!) people have adopted metric systems for measuring distance, volume, weight and so on.
Metric time
I decided it would be interesting to design a metric time-keeping system. It breaks days down into tenths (decidays), hundredths (centidays), thousandths (millidays) and so on. There are 1,000 microdays in a milliday, so the next clock units after millidays are one hundred microdays and ten microdays.
I’m not the first person to have this idea. After the French Revolution, France switched briefly to a system with ten-hour days, 100-minute hours and 100-second minutes³. It failed utterly, in no small part because throwing away all the existing clocks and watches and making new ones with new gearing was insanely expensive.
The marketing department at the Swiss watch company, Swatch, also took a run at this⁴.
I’m enough of an engineer to ignore the work of others, and to plow ahead on my own.
I want to measure time units that are meaningful on a human scale. 10 microdays is 0.864 seconds, and that’s pretty fast (it’s ten times as long as a French Revolutionary second, though). I hardly ever need to track things that fast. 100 microdays is 8.64 seconds, which is long enough to read a short email. A centiday is fourteen minutes and twenty-four seconds, which is about how much time I need to put my shoes on, find my backpack and walk to the bus stop. Meaningful intervals!
So I need just four digits to track metric time.
My metric day starts at 0000 at midnight. You can argue about whether you want to start at solar midnight, when the sun is directly beneath your feet, or you want to pay attention to time zones and daylight saving time. Measuring solar time is more accurate, but clocks are meant to let us synchronize our activity. It’s better to start at midnight in the local time zone, and to do whatever everybody else does about springing forward and falling back for daylight saving time. That way, you can schedule things with your friends who also use metric time.
There’s one more qualification — real days aren’t exactly 24 hours long, and they’re not all the same length. Inertial forces on Earth (mountains slam into a large amount of still air and slow rotation down, solar heating creates winds that slam into mountains and speed rotation up) mean the actual precise length of a day is a little bit more than, or a little bit less than, 24 hours on any given day. That means a real deciday will be different, from one day to another. That’s kind of a mess.
Of course this problem isn’t unique to metric clocks. Ordinary clocks pretend that days are all 86,400 seconds long, even though any given actual day is a little bit longer or shorter. I’ll ignore it for now and come back to it later.
My metric clock
With all that thinking behind me, I built a working metric clock.
I used an Arduino UNO board with a DS3231 real-time clock from Adafruit for high-accuracy timekeeping. The DS3231 is accurate to two parts per million, which means it can drift by up to two microdays per day. After fifty days, it could be off by one hundred microdays, which is the lowest digit on my clock. I want the clock to keep true time, and of course I have to be able to set it correctly in the first place. So I need an accurate reference for time.
There are several alternatives in the Arduino ecosystem. You can just get an Arduino board that connects to WiFi, and use the Network Time Protocol (NTP) to get current time of day. I’m opposed to “smart” things in my home — more hackable devices waiting for orders from the internet — so I decided not to use that.
In the US, the National Institute of Standards and Technology (NIST) broadcasts a radio signal with the current time from a highly accurate atomic clock it maintains in Fort Collins, Colorado. There’s a pretty robust and easy-to-use WWVB receiver available for the Arduino ecosystem⁵. NIST includes not just current time and date, but also information about when the next daylight saving time change is scheduled. That makes it easy to handle the spring and autumn clock changes. I like this design a lot, but shipping parts from Canada has taken forever — I still don’t have the receiver. Besides that, the receiver operates at a different digital voltage level than the Arduino board I’m using. There’s a way to work around that, but it’s more stuff I need to futz with.
A third option is to use GPS. GPS satellites transmit time as well as signals that allow you to figure out your location, speed and so on. Using GPS for time is nice, because unlike the NIST WWVB signal, you can see GPS satellites from pretty much everywhere on Earth. That means a GPS receiver will work in countries besides the US. After shopping around a bit, I settled on the NEO-6M GPS module as the authoritative time source for my clock.
I needed a display, so got a simple 16x2 LCD display from Adafruit.
And I dipped into my stock of wires, headers, potentiometers and resistors to connect everything up on a breadboard. Here’s what the prototype looks like:
You can see that I display the date and traditional time, as well as current metric time.
I cheated some for this version. I’ve hard-coded my timezone and am ignoring DST. I’m not bothering to reacquire the time signal periodically. Given the possibility of drift on the DS3231, I should do that every two months or so, to maintain 100 microday accuracy.
Periodically syncing to a reference — I’m not, yet — would fix any drift due to the tiny variations in the length of a day, described above. International standards organizations pay attention to that stuff, and periodically introduce “leap seconds” to restore accuracy to when midnight happens. Loading time from an authoritative reference would give me the benefit of those leap seconds, without my having to do anything else about them.
Update: There’s a proposal to abandon the leap second, and let astronomical time drift from atomic time. Clock consistency and predictability is increasingly important as more of our systems become digital. We’d kick the reconciliation can down the road, and let later people (who are often smarter people) fix it up when they need to.
The clock needs to be able to see some sky in order to get current time from GPS, of course. I just have it sitting on my desk next to the window in my home office, and it generally gets a good signal in a few seconds. It’s often nearly instantaneous.
I’m planning to use this design to build a nice desk clock for myself — get rid of the breadboard, direct-solder the connections, build a nice case, add a backup battery for power outages, add buttons for time zone, DST and so on. I’ll also sync to some time authority periodically to maintain accuracy.
I still want to incorporate the WWVB receiver instead of the GPS hardware. I hope to post an alternative design for that.
For now, though, this works great. It’s sitting next to me at my desk and is a lot of fun. If you want to make one yourself, I’ve published the WIP design on the Arduino project hub.
What I’ve learned
Here are some things I’ve noticed, now that I’ve been paying attention to my metric clock for while.
First — this is obvious now, but I hadn’t thought about it — a metric clock tells you what percentage of the day has elapsed. 2500 happens when twenty-five percent of the day is behind you. That’d be six AM on an ordinary clock, and you can do that math in your head without too much trouble. But what about when thirty percent of the day is past? 3000 on a metric clock, but 7:12am on a conventional clock.
“Percentage of day” kind or orients me in time in a new way that I enjoy.
When we schedule things on an ordinary clock we generally aim for the hour or the half hour. Round numbers are nice, and thirty minutes is a convenient minimum duration. Same thing happens when I’m working with my metric clock. When I decide to start or stop something at a specific time, I generally aim for a time that ends in 00. 100 on my clock is a centiday, or 14 minutes and 24 seconds. Those are pleasing round-number boundaries, and comfortable start and stop times. Two of them are close to a half hour, still a useful minimum duration.
One drawback of my metric clock is that I’m the only person I know who has one — it’s not useful for scheduling Zoom calls with friends, because they’re all using traditional clocks. But, by myself, I enjoy counting time in this new way. And if, eventually, we overcome the inertia that doomed the French effort, I’ll be ready!
_______________________________________________
[1] I talked with Tom White about doing math on calendars, and he loaned me a strange and wonderful book. I remain grateful!
[2] There’s a fantastic article on Babylonian numbering systems at https://www.scienceabc.com/eyeopeners/why-are-there-24-hours-in-a-day-and-60-minutes-in-an-hour.html.
[3] My friend Doug Cutting pointed out the French system to me. I’d known about their decimal calendar, but not their attempt to establish decimal clocks. I chose to disregard their failure to get their system adopted.
[4] William Vambenepe pointed me at the Swatch project.
[5] There’s a really nice tutorial on using the WWVB signal with Arduino by Keith Greiner.
