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.