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.

And if you're using heximal numbering in general, it meshes trivially into that. I recently saw someone struggling to convert "1 hour 2 minutes" into a decimal number of hours, because dealing with fractions of 60 isn't easy in decimal unless you're hitting one of the convenient numbers like "15" or "20". (For the record, it's approximately 1.0333⏨ hours; you can't write it exactly because it's a repeating decimal.) In heximal, 1h2m is 1.02₆ hours, easy-peasy.

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 - going from 12 hours per revolution on our current clocks to 36 hours per revolution makes it much harder to tell exactly what hour it is. 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://xanthir.com/hex/clock/ 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...)

(Another possibility if you wanna really move into new space is to draw from my base-6 pronunciation system, naming the weeks by the digit. So the week would go Beday, Tiday, Doday, Kuday, Grday, Paday, naming each day after its 1s-digit. This also gives us distinct letters for each day - BTDKGP - which is just a nice improvement over our current Su/Sa and Tu/Th pairs.)

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, and the one I went with in my calendar, is to just put the extra days at the end of December. December just has seven weeks, 105₆ days, with that last week having five days (six on leap years). I presume that last week would be considered to have three working days, and maintain its two weekends on either end, as a nice end-of-year treat built into the calendar. (Except on leap years, where it's a normal 4-day workweek. Or maybe 3 day Leap New Year weekend?!?)

This breaks symmetry with the rest of the months, but that symmetry has to break somewhere anyway, and putting it at the very end gives the smallest disruption. In particular, it means that date math stays trivial as long as the two dates are part of the same year - the 2nd of March and the 15th of June are obviously 313₆ days apart, because 2₆ and 15₆ are 13₆ apart and March (3rd month) and June (6th month) are 3 months, or 300₆ days, apart.

Date math gets a little more complicated anyway when you cross the year boundary (since there are 14₆ months, not a round number), so loading up that transition point with all the complexity is nice, rather than spreading it evenly thruout the year and making every bit of date math complicated, like in our current Gregorian calendar.

This does mean that some financial things are slightly more difficult than they have to be, but still easier overall than in our current calendar. Businesses track their finances by "quarters" currently, which are roughly three months long, but can't be exactly three months (Jan 1 - March 31, etc) because that would give each a different number of days, which would make the numbers hard to compare. It also would give each quarter slightly different numbers of weekdays and weekends, which further wrinkles most financial things. In the heximal calendar, if you either track by quarters (2.5 months each) or by quints (2 months each), every period is identical in length and weekday/weekend distribution, except for the last; it's just slightly longer and so needs some adjustment (but also includes the holiday seasons, and so needs special care anyway). So again, offloading all of the necessary calendar asymmetry to the very end makes things much simpler overall.

Another Possibility

Another interesting 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 could 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 is slightly better for corporate finance than my chosen solution. It also minimizes disruption to the overall week - every two months you just have a three-day weekend, easy-peasy. (It does weight the workday/weekend 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.

Overall I think my chosen solution, adding a week to the end of the year, is the best overall. Minimizing disruption to weekly schedules seems slightly more valuable than keeping quints regular.

https://xanthir.com/hex/calendar/ 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.