I was recently chatting with my friend Brenna O'Brien about datetime functions, and she was sad about how complicated time was. We joked a bit about metric vs imperial time (just use kiloseconds, it's about 15 minutes!), which reminded me that I'd thought about this in the past.

Unfortunately, metric time can't ever happen. Even if we relax our requirements to just be uniform time (define "uniform" however you like) that's easy to work with at both large and small timescales, we're still screwed.

The fundamental issue is that all the metric units have a single notion of what a "significant" unit is. It's often arbitrary, but it's important that it doesn't vary. For example, all temperature is measured in Kelvins, and using Kelvins (or a metric-prefix multiple) is valid at all temperatures.

Time is different. We have two or three "significant" units for time, and extending any of the units too far, while useful in some narrow contexts, is worthless for most purposes.

Our notion of "time" is fundamentally built on the motion of our planet in spaaaaaace. We have two relevant timescales: the "day", and the "year". Both of these are extremely important: our body has a bunch of cycles based around the "day" (actually, around a 26-hour period, which is corrected every day by sunlight levels; the body is weird), while the world around us has cycles based around the "year".

Say we tried to rely solely on days, throwing around terms like "kiloday" and the like. If we kept the same zero point to our numbering (the start of 1AD), then today would be day 735,569 (at least according to this website; I haven't tried to verify its exact values). We'd probably refer to this as day 569 of kiloday 735. However, there's no way to know what the weather is like on this day. The kiloday has no relation to our solar orbit, lasting about 2¾ years, so day 569 of one kiloday is completely different from day 569 of another kiloday.

We run into similar problems if we try to rely on the year as our base unit. Milliyears sound half-reasonable, as they're about a third of a day (8.77 hours). It's that "about" that kills you. Using the conversion ratio of 3 milliyears = 1 day, just 5 "days" later (15 milliyears), is already a half-day off - if you started counting at midnight, you end at nearly noon. So telling someone that something is happening at 100my this year doesn't give them any information about what time of day it is, which is usually fairly important.

(Earlier I said there were "two or three" significant units. The third is the second, or some multiple of it. Days and years are both based on the movement of the earth, and they drift over time - the day gets longer due to drag from the moon, and the year appears to get shorter as less of the longer days fit in one orbit. We need a timekeeping unit that doesn't vary over time as well, and the metric second does a good enough job at that.)

So, we're screwed. Too many cycles in the natural world are based around one or both of the two "significant" durations, and those two durations aren't tied to each other in any way. So we can't have metric dates. ;_;

What Can We Have?

We can approach this question in two ways.

One is that when we move to spaaaaaace, we'll no longer have the year as a significant marker. Growing plants and whatnot will happen constantly in hydroponics and similar, so there's no significant cycles based around a "year". We could switch to a day-based system at that point, as our talk about kilodays would no longer conflict with any other important information. I'd be 10.6 kilodays old, for example.

(There'd be only a third as much birthdays then. Maybe we could celebrate half-birthdays more commonly?)

The length of the day isn't sacred anymore either, for that matter. Our body cycles are still important, but perhaps we'd switch over to a "day" closer to our body's actual cycle, about 26 hours.

Since the day isn't tied to the spinning of a rock either, we can define it precisely, so it doesn't change over time. This allows us to replace the "second" as the stable time unit as well, with metric fractional days. The milliday is a fairly useful duration, covering about a minute and a half. Microdays would be a little under a tenth of a second, which is still about the right duration to be useful.

In fact, if we lengthen the day to about 27¾ hours (within the range of reasonable, for our body cycles), we can make 10 microdays exactly 1 second, allowing us to treat "second" as one of those weird names science has for certain units, like how "angstrom" is just an alternate name for a tenth of a nanometer. Bam, two reference points unified together, and all we need are spaaaaaace colonies!

Okay, But Forget Spaaaaaace

If we're stuck on Earth, we remain screwed with three unreconcilable bases. But we can at least get something a little more sensible.

Right now we group together days into "weeks" and "months", to get some useful durations less than a year. Unfortunately, neither of them are tied together either - a week is 7 days, and months are kinda sorta a twelth of a year, except rounded to the nearest day and also stupid.

We can make this work better. My friend Tantek Çelik wrote up something he called NewCalendar some time ago. NewCalendar maintains the 12-month system, and even maintains dates really well - every date in NewCalendar is at most 4 days off from the corresponding date in our current calendar. (It's worst in March/April, due to February.)

The core of this system is making each month exactly 30 days, dividing them into 6 5-day weeks. Obviously, there are 5-6 days left over, depending on the year: these are distributed between the months, every two months, to February, April, June, August, October, and on leap years, December. They're called Sundays, just for fun. The Sundays can be thought of as the 31st day of every second month, making the months alternate between 30 and 31 days, except that they don't throw off the weekdays numbering; each Sunday is outside the normal week schedule.

NewCal is meticulously thought out, with his reasoning laid out plainly on the page linked above. For example, the five-day week works much better with our decimal numbering system, as we can mentally multiply or divide by 5 much faster than we can by 7. (Quick, if today is Tuesday, what day will it be 40 days from now? In NewCal, the answer is obviously "Tuesday".) Same with six weeks per month: six is also easy to work with, it makes things that alternate weeks always land on the same day of the month, it gives us 30-day months, which is another number we seem to like, and it maintains the legacy 12 months per year.

I also like his reasoning for assigning the day names:

• New Monday - mon resembles the prefix "mono-" meaning one, providing an easy mnemonic for the first day of the week.
• New Tuesday - sounds like "twos-day", again providing an easy mnemonic for the second day of the week
• New Wednesday - keeps the traditional naming of the middle of week, which in some languages is the actual name of the day (e.g. German - Mittwoch)
• New Friday - people like Fridays, and the prefix "Fri" has similar consonant sounds to the word "four", another mnemonic for remember the fourth day of the week
• New Saturday - people like Saturdays.

(Though for serious, the third day should be Thursday, due to the close resemblance to "third", like the reasoning he uses for Friday and "fourth".)

The only thing I disagree with is his placement of Sundays, and even then I'm torn. His reasoning tying them to major Western holidays is cute, and even without that, spreading them out in the year is reasonable - it keeps business quarters almost even, for example.

On the other hand, it messes up the week math; you can't tell whether "Monday next week" is 5 or 6 days from now without knowing which Monday it is, because there might be a Sunday in that interval (and same with months). An alternative would be to place all the extra days in a bonus week at the end of the year, after December. Leap years would add the bonus day after that week. This lets us have a more consistent "next week/month" length (5 and 30 days, respectively). It's not perfect, as you still need to know if a "next month" period includes the New Year's Week (in which case it's 35/36 days away), but weeks are perfect on non-leap years; leap years you just need to know if the Leap Day is included.

Your datetime libraries thus still need to talk about months and weeks as first-class objects in the system (rather than translating them to days or something), but it's still a much easier system overall.

Finally: fuck timezones.