"221788790 SI seconds (measured at the geoid) before 1977-01-01 00:00:00 TAI" is just the official definition of the start of the calendar (to coincide with basically 10 days before the unix epoch, the northern winter solstice, and the redefinition of TAI in 1977).

Most time keeping systems now a days (including the beloved UTC) are based on the 1977-01-01 00:00:00 TAI definition because TAI is International Atomic Time (Temps atomique international) which basically runs everything when it comes precise time measurements.

A good candidate for an intersteller calendar. So to make the current date (1401510007 UNIX) more readable you could write it as 1:401:510:007

I like it a lot! That's the new stardate by the way.

"If by gay you mean the old English definition of 'fun, enjoyable and carefree,' then yes, it's extremely gay." - from the movie Role Models

I revel in my beta tier.

I use it. There's a nice date converter on the website. And if you want to use it more often, there's currently a py based ubuntu app indicator if you roll like that.

Pagans, apparently. Actually, back in the pagan days, there WERE 13 months. The year started in spring, and December was the 10th out of 13 months.

Nice. But terran computational years, month, days, hours, minutes and seconds are not decimals. Only fractions of a second are decimals.

From the site: "In order, these fields are year, month, day, hour, minute, second, fraction, designator, datemod and their ranges are roughly: ±*.[0-13].[0-27].[0-23].[0-59].[0-59].*.TC*±*, where * is any acceptable range."

So true. But people like using their own delimiters for different tasks and situations. Therefore the terran computational calendar restricts acceptable delimiters to only the most popular ones:
From terrancalendar.com#Delimiters: "The only 8 acceptable delimiters are space, plus, comma, minus, dot, slash, colon, underscore ( +,-./:_) (UTF8 hex codes 20, 2b, 2c, 2d, 2e, 2f, 3a, 5f)."

As long as you stay with a few rules, you can use any combination of delimiters you want, so:
±YY-MM-DD HH:MM:SS TC±DM is totally valid as is ±YY,MM/DD HH_MM:SS.TC±DM

This was considered, but ultimately, the terran computational calendar chose to define itself in terms of the 1977 definition of a TAI second:
"the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom" measured at the geoid (mean sea level)
Therefore, for the terran computational calendar, we actually know how much relativistic gravitational time dialation to account for, even if you are way out somewhere in a different star system, because it is the amount of relativistic gravitational time dialation that exists at mean sea level. So converting terran computational dates into future interstellar ones should be relatively (lol) easy. But, by it's name alone you've already realized that the Terran Computational Calendar is an earth based calendar and not generally expected to be used for interstellar travel.

Talking about a space travel, Barycentric Coordinate Time (TCB) and Geocentric Coordinate Time (TCG) are currently used. The former "performs exactly the same movements as the Solar system but is outside the system's gravity well" and the later "performs exactly the same movements as the Earth but is outside the Earth's gravity well".

One of the practical applications is for realtime proactive dating purposes. By default, the Terran Computational Calendar accounts for IERS issued leap seconds. But, by appending a 'year base', only leap seconds before that year will be accounted for.
So say a little over 10 years ago at 34TC you wanted to schedule a task for EXACTLY 10 years in the future, you can write that date as 44TC34 and not have to worry about the 3 additional leap seconds that have occured during that time.

Another nice thing about the calendar is that it's easy to calculate the amount of time that occured since the beginning of the year. So basically 44.5.20,19.40.4 TC means that 5*(28*24*60*60)+20*(24*60*60)+19*(60*60)+40*(60)+4 = 13894804 seconds have past since the beginning of the year. The equivalent being 44TC+13894804. Most other calendars aren't too keen on this amount of simplicity.

True, but at least any terran computational date configuration is an unambiguous instant in time. And what makes the terran computational calendar unique is its ability to either include or exclude leap seconds with 'year bases' and/or jump forward or backwards a certain number of quarters/months/days/hours/minutes/seconds with 'datemods'.

It's actually simpler is some respects. Writing two quarters into the current year can be achieved with a datemod: 44TC+2Q. This is equivalent to 44.6.14TC, and to its TC timestamp (an implied year zero and a datemod that use seconds): TC+1404172825

By default, the Terran Computational Calendar accounts for IERS issued leap seconds. But, Leap seconds can actually be ignored by applying a year base of 0. Therefore, the following two dates are the same instant in time: 44-05-20 22:16:41 TC (includes leap seconds), 44-05-20 22:17:06 TC0 (excludes all leap seconds)

I used to play a older linux game called 'Endgame: Singularity' that "casts the player as a newborn artificial intelligence attempting to evade detection long enough to transcend the physical reality, achieve technological singularity and become immortal." - wikipedia official website It's overly simplistic, but I became strangly addicted to it for a while. If you're Debian based: sudo apt-get install singularity