Some time ago I was really bored and wrote up a calendar proposal. Since then, I have had some verbal feedback but nothing particularly insightful. Today, however, I received an email from Nicholas Shanks with some interesting feedback. The following text is an amended version of the proposal reflecting feedback from Nicholas.
It occurs to me that in the forseeable future humankind will have colonies on other planets in the solar system. These planets will obviously have need of different calendars than are presently in use on the earth. This is necessitated by the fact that they have different day lenghts and substantially different year lengths. With the explosion of different calendars this provides, there becomes some need of a standard interplanetary calendar for scientific and commercial purposes. Most fiction writers just use the gregorian calendar that much of the human population of the earth uses. However, there is no particular need for the interplanetary calendar to be based on any particular local calendar. In fact, it is probably better if it isn’t. The rest of this document includes a proposal for such a calendar.
There primary design decision behind this particular calendar is that it has absolutely no irregularities by virtue of the fact it does not need to be kept in sync with any particular event. The other significant design decision is that it is based on the number ten. The following table lists the relation between the various units in this calendar.
Unit | Definition |
---|---|
second | the basic unit of time as defined by the metric system |
minute | 100 seconds |
hour | 100 minutes (10 000 seconds) |
day | 10 hours (100 000 seconds) |
week | 10 days (1 000 000 seconds) |
month | 10 weeks (10 000 000 seconds) |
year | 10 months (100 000 000 seconds) |
Contrast this with the gregorian calendar:
Unit | Definition |
---|---|
second | the basic unit of time as defined by the metric system |
minute | 60 seconds |
hour | 60 minutes (3 600 seconds) |
day | 24 hours (86 400 seconds) |
week | 7 days (604 800 seconds) |
month | between 28 and 31 days (2 419 200 seconds to 2 678 400 seconds) |
year | 365 or 366 days (31 536 000 seconds or 31 622 400 seconds) |
On January 18, 2009, I corrected a minor typo in the formatting of the above table. The typo did not introduce any errors in the table; it merely interfered with the presentation.
The gregorian calendar has normally 365 days with an extra day every 4 years except if the year is divisibly evenly by 100 and not divisible evenly by 400. Therefore out of 400 years, there will be 97 years of 366 days and 303 years of 365 days yielding an average year length of 365.2425 days or 31 556 952 seconds. This means there are approximately 3.1688 gregorian years in an interplanetary year (as defined above). Notice how cumbersome the gregorian calendar is? This is because it tries to keep in sync with a the earth’s orbit around sol yet is based on luna’s orbit around earth. It is not at all easy to determine what point in the year one is at in any particular unit if one knows it in another unit. In fact, without knowing what the year number is one cannot do a lot of conversions. Much less state is required for handling the interplanetary calendar detailed above. On January 18, 2009, I found a grammatical error in the preceding paragraph and corrected it; it did not affect the meaning in any way.
The following table provides a rough comparison between the interplanetary calendar units and the gregorian calendar units.
Interplanetary Calendar | Gregorian Equivalent |
---|---|
1 minute | 1.66 minutes |
1 hour | 2.78 hours |
1 day | 1.16 days |
1 week | 1.65 weeks |
1 month | approx 4 months |
1 year | approx 3.17 years |
The preceding table was suggested by Nicholas and is based exactly on calculations as provided by him.
Now, before the interplanetary calendar is useful, it must have a starting point. This starting point can be any arbitrary well defined point in time. It should also be possible to figure out how much time elapsed between two points on the calendar with simple subtraction; that is, no fancy gymnastics to handle time before the official starting point of the calendar. This means there must be a year 0 unlike the nonsense with going from 1 BC to AD 1 on the gregorian calendar. Now lets pick a starting point. Say, January 1, 1970 at 00:00:00 UTC.
In the original proposal, January 1, 2001 was chosen as the starting point for the calendar. However, Nicholas pointed out that since the unix timestamps start on January 1, 1970, it would make for easier calculations. This is, of course, true, and there is no compelling reason to use any other starting point.
Now we also need to pick a convenient notation for the interplanetary calendar. Anything that clearly denotes years, months, days, etc. is sufficient. The following notation seems convenient enough: year/day/hour:minute:second.fraction SST . Note that the months and weeks are left out. They can be easily extrapolated from the day (being the first and second digits respectively). Note that everything must be zero based for this notation to work well. It is also good for consistency and for ease of calculation. Also note that all fields should be zero extended (days to three digits, minutes and seconds to two digits). The identifier SST stands for Stellar Standard Time. So, the following definitions are true:
-1/000/8:64:00 SST = Nov 1, 1966 14:13:20 UTC
0/000/0:00:00 SST = Jan 1, 1970 00:00:00 UTC
0/000/8:64:00 SST = Jan 2, 1970 00:00:00 UTC
Using the above notation, it is possible to express simply the year by suffixing it with a / or only the day by enclosing it between two / characters. The time portion can be expressed separately with or without a leading / and with or without the seconds attached. There are a number of other possibilities which may or may not be useful.
Originally, the idea was to simply use a dot as the separator between the various portions of the date. It also used had a separate month portion. Nicholas suggested the above notation and upon reflection it seems to be somewhat more versatile as it permits writing the date or time independently and still be able to identify which is which. Nicholas also pointed out that the original code used for the dates (IP) is a bit too confusing, although at the time of the original, IP was not used as a common abbreviation for anything other than Internet Protocol. He suggested GST (Galactic Standard Time) but that seemed a bit to presumptuous and is also a common abbreviation for a type of sales tax. A quick google search indicates that SST is likely not going to be confused with existing time zones.
To work out the number of seconds since the start of the year, one simply removes the year from the date and removes all remaining delimiters. To work out the number of seconds since the origin of the calendar, multiply the year number by 100 000 000 and add the number of seconds since the start of the year. Due to the choice of origin, this is also the unix time value.
Converting from the unix timestamp to SST notation is relatively simple. If the timestamp is positive, the number of seconds from the start of the year is obtained by taking the remainder after dividing by 100 000 000. The year number is obtained by using the integer quotient of the preceding division. On the other hand, if the timestamp is negative, the process is the same except that if the remainder is not zero, it must be subtracted from 100 000 000 in order to obtain the seconds since the start of the year.
The following are sample C definitions for the above situation. These are by no means a complete set of functions for handing the calendar. However, they do provide the building blocks to build any other functions necessary.
// time format structure struct sst_tm { int year; int month; int day_month; int week_month; int day_week; int hour; int minute; int second; }; // the analog to time() - real simple, eh? long sst_time(long *timep) { if (timep) *timep = time(NULL); return time(NULL); } // it is entirely possible that this function can be simplified and // or optimized in some way. It is presented merely as an example. // this is your basic analog to gmtime() and localtime(). // this is NOT thread safe struct sst_tm *sst_scalartime(long offset) { static struct sst_tm tv; long t; if (offset < 0) { tv.year = offset / 100000000; if (tv.year * 100000000 != offset) tv.year -= 1; t = offset - 100000000 * tv.year; } else { tv.year = offset / 100000000; t = offset - tv.year * 100000000; } // we can now build the rest of tv from t // we'll work "left to right" tv.month = t / 10000000; t -= tv.month * 10000000; tv.day_month = t/100000; t -= tv.day_month * 100000; tv.hour = t / 10000; t -= tv.hour * 10000; tv.minute = t / 100; t -= tv.minute * 100; tv.second = t; tv.week_month = tv.day_month / 10; tv.day_week = tv.day_month - tv.week_month * 10; return &tv; } // this is the analog to mktime() // it ignores members week_month and day_week // any "out of range" values are "normalized" // no overflow checking is performed nor is any checking on timeptr long sst_mktime(struct sst_tm *timeptr) { long t; t = timeptr -> year * 100000000 + timeptr -> month * 10000000 + timeptr -> day_month * 100000 + timeptr -> hour * 10000 + timeptr -> minute * 100 + timeptr -> second; return t; }
Obviously this calendar is not one to be used for the casual marking of time in situations where the are more obvious temporal cues. However, if time is also marked per this calendar, there will be no doubts about how much time passes between two points in time nor will there be any doubts about what time is meant if this is used in long distance communications.
I have no illusions that this calendar will ever come into common usage. It was more of an academic exercise because I was bored. If someone finds it useful, all the power to them.
Nicholas also provided a simple C++ program that takes the current time and displays it in SST notation. As such a program is trivial and can easily be constructed based on the information above, I have not included it.
Back to Theoretical Ramblings index