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.

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.

(a limited set of Markdown is supported)

The time reform is fascinating, and makes the new clock face elegant. I would maybe prefer 4 quarter-days of 9 hours each, or maybe keep it like it is now with one hand doing two rounds of an 18_6 hr clock.

Your calendar reform, however, feels a bit like change for change's sake, without being inherently better. The truth is that the number of days in a year isn't whole, let alone divisible by 6, so forcing a 6-based counting on it buys you literally nothing.

The only good calendar reform I've ever seen is called Symmetry454, explained here: https://calendars.wikia.org/wiki/Symmetry454_Calendar

It keeps 7-days weeks (which is the only constraint that major religions pose on calendar reforms), 12-months years, and all months have a whole number of weeks. On leap years, December has an extra week. Simple and elegant whatever base you choose to number your days in!


(a limited set of Markdown is supported)

Alternatively, we get rid of months altogether, and stick to the ISO calendar, with years of 124_6 or 125_6 weeks. Months can remain as ethnic colour for festivities, without having to affect business or finance.


(a limited set of Markdown is supported)

I would maybe prefer 4 quarter-days of 9 hours each, or maybe keep it like it is now with one hand doing two rounds of an 18_6 hr clock.

I considered both of those. The big issue with either is the face numbers. Quarter-day in particular gets real awkward - 13₆ hours in a revolution means the hours don't line up with any round division of minutes/seconds. Half-day is better (3₆ hours and 10₆ minutes both span 1/10₆ of the circle), but you still have to deal either with the hour labels not matching the minute counts (a difficulty that takes some effort for children to get past) or put both sets of labels up.

Also, 18⏨ hours per revolution is still a little too dense to easily support reading at a glance, I think; even with the 12⏨-hour face we currently use, if you only mark the 12/3/6/9 hours (pretty common, especially on fancy watches), it can still be a little hard to differentiate at a glance between 1 and 2, for example.

It just gets a little awkward - I think the human eye can reliably distinguish 8⏨-10⏨ circle divisions at a quick glance, and 12⏨ is just at the boundary, but 18⏨ would be too much.

Your calendar reform, however, feels a bit like change for change's sake, without being inherently better. The truth is that the number of days in a year isn't whole, let alone divisible by 6, so forcing a 6-based counting on it buys you literally nothing.

"days in a year isn't whole" applies to every calendar reform, so isn't a strike against this in particular; that just dictates that leap years must exist.

"days in a year isn't divisible by 6" is a reasonable criticism to levy, however. I'll note, tho, that the 454 calendar you link to also fails that criteria, since 365/366 isn't divisible by 7 either. ^_^ All calendar reforms will run into this trouble in some way, since 365 factors into the inconvenient 5×73; the only way to kinda get around it is to make the calendar not even 365 days long (and thus bring on longer leap periods, as the 454 calendar does with its 364-day calendar and leap week)

"Change for change's sake", tho, I'll definitely dispute. In a world that was already using heximal rather than decimal, a 6-day week (that is to say, a 10₆-day week) would be quite natural; the fact that the year then nearly divides into a round number of 6-week months (making each month an oh-so-neat 100₆ days, continuing the 100₆:1 ratio of the clock) is just too nice of a coincidence to pass on.

"7 days is a religious requirement" probably wouldn't have applied in a world that started from heximal; it was back-filled by religions onto the 7-day week that the Babylonians invented for their own astrological/religious reasons. But even if it did, eh, this is my utopian imagining, so I'll pretend that religions are flexible here. ^_^

Alternatively, we get rid of months altogether, and stick to the ISO calendar, with years of 124_6 or 125_6 weeks. Months can remain as ethnic colour for festivities, without having to affect business or finance.

Oh nah those numbers are far too big for people to deal with. Not to mention nasty numbers, ugh, 124₆ weeks of 11₆ days each? The mind boggles at the math for that. ^_^ At least in our current world we have months wherein we can do simple, small math, even if the moment you cross months the math becomes non-trivial and most people just don't do it at all.

That all said, ooh, Calendar Wikia, looks like I need to do a write-up there, thanks.


(a limited set of Markdown is supported)

Gosh, I think I just realized "September - October - November - December" made a chain of 7-8-9-10. Of course, I looked at all those months several hundred times and noticed they have a numerical prefix (except November which I do not commonly associate 9 with "no-"), but not in a way that looked patterned to me.

Being someone who previously was convinced to base 12 as the 'base to switch to' first instead of base 6, I still have a fondness for base 12 when it comes to music because it makes 10₁₂ = octave. Often you will hear people say a semitone system should be used such that there are no sharps and flats (I agree with this), but then it will be rather unfairly countered saying that "then 3 octaves and +2 would be 38, how could you tell!" when base 12 would fix this entirely (30₁₂ + 2₁₂ = 32₁₂).

An interesting case to think about is if the octave just wasn't even considered as the important interval. Instead the conception would be that each 10₆ switches from the most dissonant interval to the most consonant (10₆ = tritone, 20₆ = octave).


(a limited set of Markdown is supported)

Yeah, calendars have gotten so messed up. The original Roman calendars started the year in March, so Sep-Dec were indeed the 7th-10th months of the year, and the names made sense. (And in fact, before Caesar gave them vanity names, July and August were Quintilis and Sextilis, continuing the theme!)

At some point the Romans switched it to January, for confusing reasons (probably religious, to honor Janus rather than Mars), which finally got locked in with the Caesar's Julian Calendar reform. After the Roman Empire fell the start of the year drifted around again, often starting in March, until Pope Gregory fixed it back to January as part of his Gregorian Calendar reform. I'm pissed about this. ^_^

I hadn't thought about octaves (not much for music theory), but base 6 or 12 do indeed work well for those - "20" is nearly as simple as "10".


(a limited set of Markdown is supported)

#6 - Mikko Rantalainen:

If we're going to reform calendar and time, I'd suggets going the SI route of using a single unit and prefixes. Considering that SI system has already standardized on second I'd prefer just counting seconds for the duration of the day.

Basically a meeting starting at 40ks (40 kiloseconds since midnight) would be near 11:07 in current time keeping. Adding 3ks would bring it close to noon if somebody thinks that's important for some reason. The end of day would be 86.4ks as expected. I don't believe that something happening at 42.35ks would be harder to understand than e.g. 12:35 PM. Note that the ks unit would have 10s granularity with 4 digits compared to 1 min granularity with current timekeeping.

Obviously, if scheme like this were used for some time we would all be thinking semi-short time periods in kiloseconds instead of quarter hours and hours. And SI system already has ds, cs, s, ms, µs etc. if you really want to avoid floating point.

Another possibility could be just using a day and speaking about md (milliday) and µd (microday) but I would rather avoid that due the need for leap seconds. Plus the fact that the second is already the SI base unit. On the other hand, 42 md would match an hour pretty well ;-)

However, instead of using seconds for the whole year, I'd use days as the next time unit and simply count from the start of the year. If some religious group wants to keep counting days in base 7 they can use whatever calendar they see fit for that purpose. (All Muslim countries already do this and even the start of the year does not match with the gregorian calendar and it seems to work just fine.)

The leap day could be added as the last day of the year on similar cycle as nowadays.


(a limited set of Markdown is supported)

Great work! And thanks for opening my eyes to Sept. Oct. Nov. and Dec. 🤯

But, in Years Aren't 360 Days Tho, I didn't find the second possibility. So might I suggest, between having the remaining 5 days added to the end of Dec. and spreading them evenly, something I saw in a meme like a decade ago: having a New Years Week. This special week would be considered international public holiday. A time for people and families to come together and celebrate another lapse of the earth circling the sun. It's not a 15th month, it's just like a holiday (or holy day): "set aside" from the rest of the calendar. So each of the 14 months can symmetrically have 100 days.


(a limited set of Markdown is supported)

yes, an intercalary week is definitely an option, but in practice it ends up identical to just treating it as an extension to December. You gain a slight aesthetic advantage in that the "real" months are all 100 days, but lose it when you have to figure out how to display that last week in calendars, date pickers, and so on. I think biting the bullet and just having an uneven December is the best way overall, personally.


(a limited set of Markdown is supported)

I think the 13 Moon calendar is an even better way to go about things (12 x 28-day months with 7-day weeks and one "day out of time" that starts each year). It ends up working quite well in heximal.


(a limited set of Markdown is supported)

In heximal that's 21 months of 44 days each, split into 4 weeks of 11 days each. I'm not sure how that's even remotely good in heximal; those numbers are very arbitrary and unround.

It's just as bad in decimal; the 12 months of the Gregorian is the only part that's remotely good, numerically, and that's the part you're wanting to change in favor of a moderately large prime??


(a limited set of Markdown is supported)

Also, moon calendars have some compelling qualities, but only when they actually track the moon cycle, which is not an integer number of days (it's 29 and change). Any attempt at a "simple" one will just (fairly quickly, over just a few years!) drift completely out of sync — a 28-day one will be completely backwards in just over a single year!

You can do it right, like in https://www.hermetic.ch/cal_stud/hlwc/hlwc.htm, but it takes some effort and it's not "clean". Weeks are 6-9 days long depending on exactly where the quarter-moon transitions fall, each month is exactly four weeks (29-30 days), and there are 12-13 months in a year, so years aren't remotely the same number of days.


(a limited set of Markdown is supported)

Wait wouldn't the length of the day changing not line up with sunrise+sunsets? If there's 36 hours in a day then the sun would rise like 2.5 times. Seems kinda like too much change for simple math. We'd have to live on a planet where days were actually 100 hours (36) long.

Also it doesn't line up with the moon in the same way does it?


(a limited set of Markdown is supported)

I'm... confused. I feel like you misunderstood something fundamental about the design.

"36 hours in a day" means a day is divided into 36 segments. Not, I dunno, "redefine one day to be 50% longer, made of 36 normal-length hours rather than 24".

Not sure what "sun would rise 2.5 times" could even be referring to. Are you, like, dividing 36 into 100 in decimal numbers???


(a limited set of Markdown is supported)