Before this project site went up and before I created the timer at http://metrictime.geekster.me, I worked on a prototype to ensure my math and execution was sound. In it, I came across several decisions that I had to make.

Firstly, I had, without making a goal of it, switched to using the <year>.<day of year> date format. So, today being January 11, 2017 is 2017.11. It was something I started on January 1st and just did. I can only attribute that to being a geek. A few days ago I decided to give metric time a run after having looked at it 15 years ago.  I figured that it would be appropriate since I’m changing how I do dates (I wonder if I can use that format on the next check(que) I write, I’ll let you know if the bank rejects it).

So, being a Trekky, I thought, maybe I’ll try Stardate instead!  I remember learning to do the calculations 15 years ago (I worked at an online Calendaring company, so date and time calculations were kind of my thing). I looked up Stardate and found out that the format changed in 2009 to, you guessed it: <year>.<day of year>. Woop! I had already converted to Stardate without knowing it.

Stardate

Consideration 1: The period is a separator. The Stardate was fairly straight forward. But it’s important to note, that while the move to metric time requires the standard use of a single number with a decimal, the Stardate, while looking metric, does not use the decimal as a precision indicator on a single number, but as a number separator. So, 2017 is a separate number from 365. In 2017.365, the decimal number does not go to 999 then roll over.

Consideration 2: 0 or 1 based index. There was also the decision to start at 0 or 1 day. In metric, the first number is 0. If you look at military time, the first hour is 00. So, while 24 hours in a day, the 24th number used is 23.  11:59pm is 2359hrs. However, for the date, because it’s not metric, simply the count of the day of the year, I decided to stick with Jan 1 being day 1, not day 0. It didn’t make sense to mix the metric up in this. As well, people, when counting, more intuitively count the first apple as apple 1, not apple 0. Which makes the global conversion a little more intuitive to the common (as opposed to Engineering) person.

Consideration 3: To pad or not to pad. The last consideration was whether to left pad the day. So, either Jan 1, 2017 is 2017.1 or 2017.001.   I looked to the use of Stardate to separate this, but I have seen it used both ways. I say that, but the second way (padded) is actually incorrect in how they use it.  You can see that Spock’s Obituary had 2 space padding, but there are 3 numbers that represent the date of year.

Which means, they are not using true left padding here.

And from the verbal use, the padding meant nothing.  You can listen to how it’s used here. Basically, 2017.11 would be read “twenty seventeen point eleven”. It would not be read “twenty seventeen point oh one one”.  So, the date I’m using is simply <year>.<day of year> without any padding, etc. Oct 27, 2017 would be 2017.300. The second number is not right padded, because it’s a number by itself. The decimal use can be confusing if you don’t understand that.

On a side note, has anyone noticed that Stardate is based on the revolution of the Earth around the sun and not some universal number? Which basically, and again, makes humans the center of the universe. People who live on Venus would have a 224ish based calendar. Why would ours trump theirs? Especially if humans are so far behind in the space race? But I digress…

Metric Time

Consideration 1: Separated or not. For the time format, I had played with using separators, such as colons and periods. However, when I started talking the numbers out loud and considered, ya know, metric, I realized the only format that would be acceptable is a single decimalled number.

Consideration 2: Units. If you look at metric time formats on the internets, you’ll see that there are several versions out there, from French Revolutionary Time to Swatches attempt at making more money. Unfortunately, Swatch came up with .beats (an attempt at branding). The reason I didn’t go with Swatch’s suggestion is because I don’t like that they tried to commandeer the fundamental of time for money (but what other reason would you have I guess??). So, I tried to come up with other units, but the Tsangaris didn’t work well… and see you in 2 Johns didn’t fit with. I had briefly, with my tongue sticking through my cheek, tried to come up with phonetic for my first and last initials (jt or jet). So, see you in 3 jets. Or, I woke at 5 jet. Except, that sounds horrible. I pulled my tongue out of my cheek and talked to others. A friend (I haven’t attributed this to him because I haven’t asked to use his name in this, when I do I’ll update) suggested ticks as that wasn’t currently used for anything major and has not intuitive associations with it as far as units go. It sounded good. It rolled off the tongue well. So I used it.

Consideration 3: UTC change (NO!). However, their application had some holes in it. Firstly, they tried to change UTC. So, the new UTC would be UTC+1. I think that’s dumb. When proposing a new system for people you can’t just tell them to about face, and then they are instantly facing the opposite direction. When turning they will face in every single direction between one and the  other. At every step they could decide the effort isn’t worth it. The world already knows UTC and changing that seems arrogant (maybe that’s what offended me first).

Consideration 4: Timezones. Also, they proposed having one time for the world and timezones wouldn’t exist. I’m not saying that this may not be a possibility in the future (but I haven’t decided), but people know time zones. They wake up at 7am and the sun is up. Swatch suggested that 7am (in metric) would be the same everywhere. So, I could be going to be at 7am while you’re waking up at 7am (assuming we still rise and fall with the sun).  The world, again, is not ready for that. And it would make it a lot harder to transition from one format to another if you’re changing the fundamental of time as well. I stuck with timezones. The metric I use is based on changing your current, local, time format from seconds/minutes format to metric.

Issue 1: Miscalculation. If you look at other metric timers on the web, I mean, actually watch them, you’ll see some inconsistencies after a bit of time (number skips, delays, etc). I found my original prototype had a skip every 6 or 7 standard seconds. I’m sure I had my math right according to what was on the Swatch wikipedia, but I couldn’t figure out why my timer was skipping numbers. So, I started from scratch and did the math for myself. What I found was that the Swatch wikipedia was missing an order of precision. Meaning, their math was based off the second as the smallest unit of measurement, but to get an accurate metric time (with the assumption that we are creating metric as a function of standard time) you have to use the millisecond as the smallest factor in the calculation. Once I did this, the counter worked like a charm.

Issue 2: Not true metric. While I have the timer working as expected. There is a fundamental issue with all metric converters in that true metric will go from 346.453335246755432 to 346.453335246755433. No matter how precise you get, the number will always increment 1. However, because our metric time is a function of standard time, the metric accuracy will always be dependent on the precision of the standard units. Which means, it will never be truly metric. There is a solution to this, which is that of creating integrated circuits using quartz crystals that have a frequency compatible with metric time. That effort, which is what I had actually contemplated 15 years ago, is so far beyond anything I will be attempting as to render it an academic ideation at best. Not going to happen. 🙂 This is a fun project and I have robots to build before I sleep. And robots to build before I sleep.