How to make this base-10 metric time concept work

Question

I am trying to make a fake metric-time app to prank some friends when we take a trip to Canada soon and would like to know how I could make this work conceptually.

I already know that the time is already considered "metric", but for this prank to work, the prank-ee must believe that it is not.

So, if we assume that "regular time" means the time scale that everyone in the world uses, (24 hours in a day, 60 seconds in a minute, 60 minutes in an hour etc.), then how would I go about somehow linking "regular time" with "metric time" (100 hours in a day, 100 seconds in a minute, 100 minutes in an hour) so as to create a believable metric time clock.

(by believable, I mean not making seconds go by excessively fast in order to compensate for the 913,600 extra seconds in the day)

To put it simply
I want to somehow make a believable time scale based on powers of 10 that could feasibly replace our current timekeeping system, while still being tied to our current timescale (so 80:00 AM "metric time" would fall at the same time everyday).

Bonus points if you can explain a realistic way to do this where each increment (i.e. seconds in a minute, minutes in an hour etc.) is the same.

Extra bonus points if someone can propose a solution where I won't have to implement a massive time-jump at midnight in order to make the times correlate.

I understand that this may not be the best place to ask this question, but since I'm not asking how to implement this in code, but rather how the concept would work. Therefore I figured this would be the best place to ask.

Answer 1

In imperial units, a mile is divided into yards, feet, and inches (like days are divided into hours, minutes and seconds). However, in the metric system the subunits are based on powers of ten and named with prefixes: the kilometer is divided into meters, centimeters, millimeters, etc.

For a metric time system, I would apply the same concept to the base unit of one day. Instead of hours and minutes, you would have subunits like centidays and millidays.

For example, 10:18:42 pm would be equal to:

$$ \frac{1}{2}~\text{day} + \frac{10~\text{hours}}{24~\text{hours}/\text{day}} + \frac{18~\text{minutes}}{24\times 60~\text{minutes}/\text{day}} + \frac{42~\text{seconds}}{24\times 60\times 60~\text{seconds}/\text{day}} \\\approx 0.92965~\text{days} $$

(Where the extra half-day comes from the pm.)

The subdivisions of the day would be:

$$ \begin{align} 1~\text{day (d)} &= 1~\text{day} \\ 1~\text{deciday (dd)} &= \frac{1}{10}~\text{day} = 2~\text{hours}~24~\text{minutes} \\ 1~\text{centiday (cd)} &= \frac{1}{100}~\text{day} = 14~\text{minutes}~24~\text{seconds} \\ 1~\text{milliday (md)} &= \frac{1}{1000}~\text{day} = 1~\text{minutes}~26.4~\text{seconds} \\ 1~\text{microday ($\mu$d)} &= \frac{1}{10^6}~\text{day} = 86.4~\text{milliseconds} \end{align} $$

For fun you can come up with nicknames for the different units. E.g. deciday could be "metric hour," "deci," or (based on the abbreviation dd) a "dud." Milliday could be "metric minute" or "mid."

We could add an additional "convenience unit" also based on the powers of ten:

$$ 1~\text{metric second (s$_\text{m}$)} = \frac{1}{10^5}~\text{day} = 0.864~\text{seconds} $$

So we might write our time from before (10:18:42 pm) in metric time as:

$$ 9~\text{dd}~29~\text{md}~65.3~\text{s}_\text{m} $$

Or simply as 9:29:65 or even 0.92965.

This makes the representation of dates easy too, since we can just put a whole number of days in front of the decimal point. In fact, we could throw away months altogether and just use day numbers. For example, today is 2016-02-11 (eleventh of February, 2016). January has 31 days, so February 1 is day 32, and February 11 is day 42. Thus, in the metric calendar today is "day 42 of 2016."

Putting it altogether, 10:18:42 pm, Feb 11, 2016 is 42.9:29:65, 2016.

---

All joking aside, this is close to a real time system: the Julian Date. There are a lot of variants, but they all count decimal days from some starting point.

Let's use the same date from before as an example. In the "traditional" Julian date, 2016-02-11T22:18:42 is equal to JD 2457430.429653. Note that the decimal part is almost the same, but there is a difference of 0.5. The Julian date starts at noon, not midnight—it was invented by astronomers, and this way it doesn't roll over in the middle of the night when they are doing their observations. Note also that I assumed our time was in GMT: there is no concept of time zones for the Julian date, so we need to convert the time to GMT before converting to JD.

There is also the "modified" Julian date, defined as MJD = JD − 2400000.5. Our example time is MJD 57429.929653. The modified Julian date is used frequently in the space industry because it it shorter than the full Julian date (and easier to represent in computers with limited precision) and it starts at midnight like most other time systems (where the factor of 0.5 comes from).

Fun fact: the "stardates" of Star Trek were based on the concept of the Julian Date.

---

One final point: I mentioned time zones in the previous section, and for a large country like Canada time zones are pretty much a necessity (although China seems to be OK without them). There are two options:

• Base the metric time on the real local time. So if you're in Ottowa (EST/UTC-5), and the local clocks say 10:18 pm, then your metric clock would say 9:29. At the same time in Vancouver (PST/UTC-8), the local clocks say 7:18 pm and your metric clock would say 8:04. This is the easiest to implement, since you can just do the calculation based on the phone's local time, which is usually what you get from the builtin date functions by default. The differences between the time zones are not a whole number of duds or mids, but that's just the kind of wierd, stupid stuff that happens in real life.

• Make up your own time zones! This makes the app logic nontrivial and is probably too far for a joke app; but I like to think about this sort of stuff, so here goes.

  If we restrict ourselves to time zone offsets of whole duds, then there are only ten timezones in the world, each about 36 degrees wide. Canada is wide enough to have three of them (so there is a two-dud difference between the eastern and western time zones). In order to make things plausible, I'll make the metric time zones by merging the real time zones to make our lives a little easier.

  The +0 timezone is centered on 0 degrees longitude. The "ideal" dividing lines would be 18 degrees to either side, so the western edge (dividing the +0 and -1 time zones) passes right through Iceland. The -1 timezone is 36 degrees wide and includes most of Greenland, just cutting through the easternmost tip of Canada. The -2 timezone includes most of the Great Lakes, stopping just before the west tip of Lake Superior. The -3 timezone contains Alberta, Saskatchewan, and Manitoba. It ends just after the west coast of the United States. The -4 time zone includes the west half of British Columbia and the Yukon.

  These ideal divisions actually line up fairly well with existing time zones. The new -2 time zone lines up with UTC-4 (Atlantic time) and UTC-5 (Eastern time). The new -3 includes UTC-6 (Central time) and UTC-7 (Mountain time). Finally, the new -4 time zone includes UTC-8 (Pacific time), as well as UTC-9 (Alaska time). You might call the new time zones "Eastern Metric Time," "Central Metric Time," and "Pacific Metric Time" (with abbreviations EMT, CMT, and PMT).

  For the actual implementation, I would get the current UTC time from the date libraries and convert it to metric time. Then find the user's current UTC offset, and map it to one of the new time zones (all the cases above are just newTZ = floor(oldTZ / 2)), then add or subtract that many duds from the metric time. The borders would shift during DST (e.g. locations using PDT move to the -3 time zone, and locations on CDT move to the -2 time zone), but we can live with that. The floor(TZ / 2) trick seems to work reasonably well across the rest of the world too.

Answer 2

The method I've always used is 10 hours per day, 100 minutes per hour, 100 seconds per minute, like 2012rcampion suggests.

Then there are ${24\over 10}=2.4$ normal hours per metric hour, ${24\cdot 60\over 10\cdot 100}={1440\over 1000}=1.44$ normal minutes per metric minute, and ${24\cdot 60\cdot 60\over 10\cdot 100\cdot 100}={86400\over 100000}=0.864$ seconds per metric second.

If you're building your own clock on a microcontroller or using small electronics, you'd want to update the metric second every 864 normal milliseconds.

If you're just writing software on a laptop or mobile device that has simple access to normal time functions, then you can just get the current time of day in seconds.

I used Visual Basic.Net, made a couple labels, two textboxes, and a timer set to update every 50 milliseconds (though you could do it less often, especially if you're not showing both times back-to-back).

Here's the VB.Net code using VS 2013. Create a new forms project, create a textbox named txtNormal, another named txtMetric, a timer named timClock then paste the code into the class file and it should work.

Private Sub timClock_Tick(sender As Object, e As EventArgs) Handles timClock.Tick Dim Now As Date = DateTime.Now Dim normalSeconds As Integer = Now.Second Dim normalMinutes As Integer = Now.Minute Dim normalHours As Integer = Now.Hour Dim totalSeconds As Double Dim metricSeconds As Double Dim metricMinutes As Integer Dim metricHours As Integer totalSeconds = Now.TimeOfDay.TotalSeconds metricSeconds = 100000 * totalSeconds / 86400 metricHours = Math.Floor(metricSeconds / 10000) metricSeconds -= metricHours * 10000 metricMinutes = Math.Floor(metricSeconds / 100) metricSeconds -= metricMinutes * 100 metricSeconds = Math.Floor(metricSeconds) txtNormal.Text = normalHours.ToString("00") + ":" + normalMinutes.ToString("00") + ":" + normalSeconds.ToString("00") txtMetric.Text = metricHours.ToString("00") + ":" + metricMinutes.ToString("00") + ":" + metricSeconds.ToString("00") End Sub

Here are several screen grabs of a simple program running with different time zones:

If you want to go further, you can turn weeks into 10-day periods, with 36.5 weeks per year, though obviously there's no way fully convert to a base-10 metric calendar without adjusting the Earth's rotation.

Of note, France actually used this exact time system from 1794 to at least 1801, although it was mandatory only until 1795, and they used a 10-day week from 1800ish to 1805. In their system, the clock and units were called "decimal" instead of "metric", even though they introduced the metric system at the same time, and they sometimes used the unit "décime", one-tenth of a decimal hour, or ten decimal minutes. During this era, astronomer Pierre-Simon Laplace used a decimal watch that ended up being the basis for astronomers using the decimal time 2012rcampion mentions in his answer.

Answer 3

I am going to point you to an existing solution, which is somewhat similar to what you are suggesting, but not sure whether this is what you want. Hackworth has also mentioned it in a comment.

There's a time system named Swatch Internet Time. This was invented by Swatch (hence the name).

The day is divided into 1000 beats. That makes one beat around 1 min 26 seconds long. So 500 beats would be noon, 250 beats 6 am etc. (The clock doesn't have time zones, so those times would be UTC+1, but of course you could ignore that for your purpose. There's a converter on the Swatch website)

What makes this neat in my opinion is that 1 second, corresponds to 0.011574 .beats, which is almost 0.01. So if you make a clock or an app, the change in this decimal will be virtually indistinguishable from seconds. So you could have an indicator for this second decimal and it will 'tick' just as fast as a second indicator on a normal clock.

Answer 4

I would just like to point out that a more progressed world should rather use a base 12 system as it has more factors making it great for quick calculations. As this article points out.