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) The gregorian calendar has normally 365 days with an extra day every 4 years except if the year is divisibly evenly by 100 and no 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 know what the year number is one cannot do a lot of conversions. Much less state is required for handling the interplanetary calendar detailed above. 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, 2001 at 00:00:00 UTC. 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.month.day.hour.minute.second Note that weeks are left out. They can be easily extrapolated from the day of the month; it is the first digit. Note that everything must be zero based for this notation to work well. It is also good for consistency and for ease of calculation. So, the following definitions are true: -1.0.00.0.00.00 IP = Oct 31, 1997 14:13:20 UTC -1.0.00.8.64.00 IP = Nov 1, 1997 14:13:20 UTC 0.0.00.0.00.00 IP = Jan 1, 2001 00:00:00 UTC 0.0.00.8.64.00 IP = Jan 2, 2001 00:00:00 UTC One can leave out all the decimal points and one now has exactly the number of seconds since the beginning of the calendar for years greater than or equal to zero. For pre-origin dates, one cannot do so. For pre-origin dates, one must take the month, day, hour, minutes, and seconds must be added to the value of the year number multiplied by 100 000 000. Note that this works for years on both sides of the origin. The reason for this is that dates count naturally from the beginning of the year and the beginning of the day. The formula for doing the convserion from "seconds since the origin" is as follows: scalar = s if s >= 0 or scalar = 200 000 000 * floor(s / 100 000 000) - s if s < 0, where s is the seconds since the origin and scalar is a value suitable for creating the notation described above. If the resulting value is less than nine digits it is to be zero extended (on the left) until it is at least nine digits long. For those of you who use the unix style time representation, it is trivial to convert between the seconds since Jan 1, 1970 00:00:00 UTC and the interplanetary calendar. One needs only to subtract 978307200 from the unix number to obtain "seconds since the origin". This can then be converted as noted previously to obtain a date notation in the usual notation. 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 ip_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 ip_time(long *timep) { if (timep) *timep = time(NULL) - 978307200; return (time(NULL) - 978307200); } // 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 ip_tm *ip_scalartime(long offset) { static struct ip_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 ip_mktime(struct ip_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. One may use just the "year.month.day" or "hour.minute.second" independently. For convenience, one may use a hyphen or slash to separate the first form but the order must remain the same. One may use a colon as the separator for the time of day also but it is recommended that that not be done. 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. December 30 - 31, 2000 CE -1/9/99 IP :) Code snippets corrected January 2, 2001 UTC 0/0/1 IP :) Explanation of leap years in the Gregorian calendar corrected on Februay 19, 2001 UTC 0/0/43 IP :)
A Calendrical Proposal
Back to Theoretical Ramblings index