2000
A Calendrical Proposal by The Lost Wizard

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 
242
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   :)

.

0