Handling Time in Base 6

Last updated:

In previous posts (here and here) I lay out arguments for why base 6 (heximal) is superior to base 10 (decimal) or any other base, due to its numerical properties.

Arithmetic is all well and good, but I think heximal actually has some great arguments for its superiority in the real world, too. Let's go over some of them.

"Decimal" Time Kinda Sucks

We already don't really use decimal for time; we use a bastardized mostly-base-60 system: 60 seconds makes 1 minute, 60 minutes makes 1 hour, and then (breaking the pattern!), 24 hours makes 1 day. Like the Babylonians did in their time, we write this using alternating base-6 and base-10: the 1s digit cycles thru all ten values 0-9, while the tens digit only cycles thru the six values 0-5.

All this adds up to a lot of confusion for children first learning how to read time, and persistent confusion thru adulthood for people needing to do time math; it's not unusual for someone, at first glance, to read a timer set to 1:20 as "120 seconds left", when it's actually 80 seconds. Or take movies, which usually have their runtimes reported in minutes - how long is a 132 minute movie? (2h 12m, but that takes a moment of thinking to calculate.)

That 60/24 inconsistency also contributes to more time confusion in the form of clock faces generally being labeled 1-12, with children having to memorize that "3" only means 3 for the hour hand; it means 15 for the minute or second hand.

How Does Heximal Help?

It turns out that we can avoid all that by switching to heximal time! Let's go over the details.

First, the scale. We can use a nice, simple 100₆:1 ratio for all three time units: 100₆ (36⏨) hours to the day, 100₆ (36⏨) minutes to the hour, and 100₆ (36⏨) seconds to the minute. This gives us time periods very close to decimal time: the hex hour is 40 dec minutes, a little shorter than the dec hour but still able to serve a similar purpose as "a large unit of time"; by a lucky coincidence the hex minute is almost exactly a decimal minute (about 1m4s in dec); and the hex second is just under two dec seconds, still fairly reasonable to use for counting off moments. (Bonus: 1/10₆ of a hex second is 1/3 of a dec second, which is still actually countable by humans, unlike 1/10⏨ of a dec second.)

More importantly, time math is now trivial. Quick, what's 250 seconds in minutes? In hex, it's 2m50s; in decimal it's [does some quick math] 4m10s. Scale that up to hours, too: 3 hours 10 minutes is 310₆ minutes or 3,1000₆ seconds in hex.

All this means that children, when first learning time, will no longer struggle with the inconsistencies of base-10 numbering with base-60/base-24 time. Counting and time all work the same exact way, mutually reinforcing each other in learning. And this carries over to adulthood, making time math much simpler overall.

A Heximal Clock

Interestingly, a heximal clock would feel pretty similar. Minutes and seconds are already counted 00-59⏨; in hex they're 00-55₆, and your intuitions work the same. For example, "half past" is :30 in both hex and dec time. It's only the hour that would significantly change, from either a 1-12⏨ double count (in the US) or a 0-23⏨ count (elsewhere) to a 0-55₆ count in hex.

Actually rendering a hex clock is an interesting challenge. Due to the aforementioned minute/second closeness, the minute and second hands of a hex clock can work identically, going once around the circle for each hour/minute. It's probably not reasonable to do the same for hours, however, because of the loss of precision. It's not very important whether you can tell at quick glance whether it's :11 or :12 past the hour, but it's very important whether your alarm clock is showing the hour itself as 11₆ or 12₆; one is 7:20am in decimal time, the other is 8am, and the difference can be whether you're late to work or not!

There's a few possible ways to resolve this, but the one I think I prefer overall is to have two hour hands, one pointing to the tens digit and the other pointing to the ones digit. I've created a live example of this at https://heximal-clock.glitch.me that you can check out. Reading it is almost identical to reading a normal clock; you just have to take into account the pair of hour hands, instead of reading a single hand and remembering which half of the day you're in.

I suspect that it'll be useful to give a name to the values of the "slow" hour hand, what one full rotation of the "fast" hand is, if for nothing else so you can refer to that hand without having to say "fast hour" vs "slow hour". I suggest "span" for this unit, one sixth of a day, so you have the span hand and the hour hand. This is a reasonably useful period of time anyway: we already informally divide up days into 8-hours units for sleep/work/else, so each of those would be two spans. A half-day at work would be one span, etc.

Heximal Dates

We can take this nice system a little further, into dates. The year is 365⏨ days, remarkably close to 36⏨×10⏨; in hex that's 100₆×14₆ or 1400₆ days (exactly 1405₆).

First, if we're using heximal, clearly we want to use a six-day week; the seven-day week is a weird artifact of Babylonian astrology (based on the seven moving heavenly bodies they could see). That means the year is 140₆ weeks, with 5 days left over.

(This has some knock-on benefits; sticking with a 2-day weekend means a 4-day workweek, which is honestly better for humans, but not a huge change in overall working days. (It's definitely not a 20% reduction, just ~6.5% reduction, from ~260 working days to ~244.))

(Tangent: a six day week means we have to drop a day. Which one? Maybe Wednesday, to keep the symmetry of a SMTTFS week. Or maybe Tuesday or Thursday, so the work-week has unique starting letters for its days, MWTF. While we're here, Sun/Mon/Sat are all still named after those original heavenly bodies; maybe we could go back to that with the other three? Skipping Mercury because it's hard to see anyway, swap Wednesday for Vensday (Venus), Thursday for Marsday, and Friday for Joday (Jovian). Hey, if it's good enough for the French...)

With that down, we've got some choices. We could stick close to the existing calendar, and do a dozen (20₆) months in a year, each with 50₆ (30⏨) days. That's not too bad, but we're so close to even rounder numbers: we can alternately go with a six-week month (100₆ or 36⏨ days), then we have ten (14₆) months in the year.

This feels really good - 100₆ seconds in a minute, 100₆ minutes in an hour, 100₆ hours in a day, and 100₆ days in a month. The perfect scale-up only breaks when you finally reach a whole year, and even then, ten isn't a bad number in heximal. (Certainly no worse than twelve is in decimal.)

This gives us some beautiful day numbering, too - each month starts on Sunday the 1st, and subsequent Sundays are the 11th, 21st, 31st, etc.

(Since we only need ten month names, I presume we'd drop July/August as the most recently-altered month names, making Sept-Dec's 7-10-derived names make sense again.)

Years Aren't 360 Days Tho

"But Tab!" I hear you cry, "The year isn't 360 days, it's 365! You just dropped those last five days!" You're right, we have to deal with those 5 (6 on leap years) days. I think there's only two reasonable possibilities.

The first possibility comes from my friend Tantek, with his NewCalendar project, a proposal to regularize the existing calendar with minimal disruption into 12⏨ 30⏨-day months, each of six 5-day weeks. He deals with the leftover days by distributing them thruout the year - every second month has an extra day at the end. It's technically outside the week/month system, to avoid disrupting the day numberings, but it basically just means that the months alternate between 30⏨/31⏨ days. (December is the exception, with 30⏨ days in a normal year, and only getting its 31⏨st on leap years.)

We can adopt the same, giving every second month an additional intercalary day ("intercalary" = not technically part of the calendar, so month/week numbering isn't interrupted). Because we're starting from ten months, the pattern for a normal year is kept absolutely; it's a perfect 100₆/101₆ alternation. In leap years the leap day goes at the end, giving the tenth month 102₆ days.

I like this solution because it keeps the year more regular overall. Every 200₆ days there's a single bonus day, making each "quint" of the year exactly 201₆ days long (the final one is 202₆ days on a leap year, an unavoidable complication). This helps things like corporate finance, as you don't have to normalize quinterly earnings by the number of days in each to make them comparable, like you do in our calendar (or else make the "quarters" not line up with the calendar exactly, which has its own problems). It also minimizes disruption to the overall week - every two months you just have a three-day weekend, easy-peasy. (It does weight the work/end ratio slightly further toward weekends, tho.)

The big downside of this is that it breaks nice date math - the distance between the 2nd of one month and the 2nd of the next is either 100₆ or 101₆, depending on which month you started from. Ordinary people would have to worry about off-by-one errors all the time when doing mental date arithmetic. And this doesn't just affect mental math; anything based on weekly schedules has to account for every dozenth week effectively having seven days - medication, work schedules, etc.

So, the second solution is to just insert an entire week at the end of the calendar - nine perfect 100₆-day months, and then December is 105₆ days (110₆ on leap years). In work schedules, I presume this would just be treated as a 3-day work week (or on leap years, just a normal week), a nice little treat at the end of the year. No reason to make this week intercalary, just drop it in as a normal seventh week to the month.

This means that the fifth quint does need to be normalized when comparing cross-quint numbers, but that's still an improvement over our current "every single quarter is a different length" situation.

On the plus side, date math remains absolutely trivial as long as the dates are within a single year - January 5th and May 10th are separated by exactly 405₆ days, a number which requires no more thought than realizing "May is four months after January, and the 10th is five days after the 5th". Anything which relies on weekly schedules has to adjust itself only once a year (and only on three out of every four years, at that). Dates crossing a year need some thought, but that's already the case today, so it's not a new problem.

(Relatedly, since the months are all the same length, it makes it more reasonable to instead stick with quarters rather than quints, each 2½ months (230₆ days) long. The last quarter still needs normalization, but the first three are exactly the same length and can be directly compared to each other.)

Overall I think I prefer the second solution, adding a week to the end of the year. Minimizing disruption to weekly schedules seems slightly more valuable than keeping quints regular.

https://heximal-calendar.glitch.me/ is a live calendar showing off this design. (I didn't add the ability to display additional years, as they look exactly identical save for December's last week.)

Next Time

Next, I overthink the other numeric systems in our lives, and argue why they'd be better in heximal.

(a limited set of Markdown is supported)