Yup omitting leap years every 128 is more difficult for people to calculate in their heads when it gets up to bigger years 640, 768, 896.... but they'll only have to do that 128, and a computer will probably do it for them automatically, and a lot of people won't even have to worry about it at all during their lifetime...unless they're calculating dates, and if they are, then they're hopefully using a calculator in which case, this algorithm is much easier.

I think the terran computational calendar is extremely easy to memorize and reproduce. And you don't need tables to do it either. I'll just quote the website:
Level of Permanency
The terran computational calendar maintains a very high level of conformity and permanency:
* Each full month, day, hour, minute, second, week, and quarter are of constant length
* Each time measurement unit begins at 0
* Years, decades, centuries, etc. are integer based
* Each year begins near the northern winter solstice
* Each quarter lasts for 3¼ months or 13 weeks
* Calendrical drift is suspended by including leap days in years that are a multiple of 4 but not of 128
* All written dates are unambiguous.
* Any date tells you explicitly how many years, months, days, hours, minutes, and seconds have past since the terran computational epoch.

zero-basing: Most standards (like ISO 8601, UTC, TAI) today define 00:00:00 to be the equivalent of midnight and therefore occuring on the next day...and the same goes for the terran computational calendar. And the the beauty of zero-based numbering and precise dating is that you can define instances in time like that. But if you can prove that .9999... is equal to 1, then you could write midnight as 23:59:59.999..... and also have midnight be on the previous day. It's just a lot harder to write. I had a middle school substitute teacher back in the day that told me that midnight occurs on neither side, but simply in between the two, so, technically, it's in neither day.

Well, if it's any consolation to you the terran computational calendar would ensure that if you're born on a leap day, it's still always ends at the beginning of the year, And in general, if you are born on a leap day, then in most years you will only have birth moments... which is pretty cool. You could stay up til the end of the previous day and then at precisely midnight you (and whoever you're celebrating with) can scream at the top of your lungs and be silent the moment after.....because it's not your birth moment anymore.

Writing dates like 44TC+2Q are good for things like refering to quarterly statements, and what not. So instead of saying "By 1Q of 44" like we do today, you can just write it as the actual date that's unambiguous and easily parsed.

'designator' just means things like UTC (which you should be familiar with). The terran computational calendar designator is generally TC (unless you're using a year base, but I'll keep it simple in this reply).

'datemods' might take a little used to, but they DEFINITELY can be used to represent local timezones as well as daylight savings time. They can even represent timezone offsets that are defined in a number of minutes instead of hours.
PST (Pacific Standard Time), an offset of -8:00 in UTC is a +8H datemod in TC
PDT (Pacific DaylightSaving Time), an offset of -7:00 in UTC is a +7H datemod
NPT (Nepal Time), an offset of +5:45 in UTC is both a -345M and a -5H45M datemod
And while timezone abbreviation can be useful for know where dates originate from, they are often confusing. Would you ever want to memorize the offset of all the above timezone abbreviations? With offsets and datemods, you don't have to do that, you just have to realize how far away from greenwich someone is.

In terms of delimiters, the acceptable delimiters are space, plus, comma, minus, dot, slash, colon, underscore ( +,-./:_) (UTF8 hex codes 20, 2b, 2c, 2d, 2e, 2f, 3a, 5f) So please feel to write the terran computational date in which ever way you're most comfortable with using those delimiters: 44/5/21 4:46:17 TC+7H, 44-5-21 4:46:17 TC+7H, 44.5.21,4.46.17 TC+7H.

Well, if a calendar from KOI-3284.01 works their own orbital periods into their calendar, I would definitely hope they'd name it something like 'The KOI Pond Calendar'.

Maybe, unless you have some sort of machine to detect your own change in relitivistic mass due to your speed and the amount of gravometric distortion caused by nearby stars and planets, in which case, you could probably do pretty well in syncing up your clocks, or at least you'll know what time it will be if you ever decide to return to earth.

Just in case you didn't realize it for some reason or other, when I wrote: 5*(28*24*60*60)+20*(24*60*60)+19*(60*60)+40*(60)+4 = 13894804
(28*24*60*60) = 1 month
(24*60*60) = 1 day
(60*60) = 1 hour
(60) = 1 minute
This is easy to remember and makes sense, right?

Well, it's definitely convenient, right?
In my own opinion, the most important things to do in an all encompassing timekeeping system for the earth are to synchronize years to an initial point, synchronize days to an initial point, and a to define a constant unit that will enable you to maintain these snychronizations.
Since TAI SI seconds are the constant unit used in the computational calendar, I'd have to say, YES, being able to "calculate the amount of time that occured since the beginning of the year" is very important for anyone interested in using the calendar.

Yeah, when converting between the terran computational calendar and other calendars, it's all about converting them into eachother's timestamps, and that generally works, although UNIX timestamps are a little tricky since they loop back on the same second during a leap second, which can become annoying. So unless you know the corresponding UTC date, it's impossible to know which second the UNIX timestamp refers to during the leap second and the one following it, because the timestamp remains the same for two seconds.

I see your point, different date notation may get confusing, but all dates represent unambiguous instants in time. In general, the extra components for the terran computational calendar would only ever be used in specific domains for specific purposes. Year bases are useful in real time applications. Quarter datemods like 44TC+2Q are useful for business, so you don't actual have to use verbose language to descibe quarters. Week datemods like TC+2318W6D (2318Weks 6Days after the terran computational epoch) could be useful in civil/government agencies who use weeks not months in their dating processes.

But, in general, any further stadardization of this calender would probably just look like this: 44-5-21 3:18:54 TC+7H and that should be familiar to pretty much anyone once you get use to the idea of a datemod being somewhat the opposite of a timezone offset.

Barycentric Coordinate Time (TCB) and Geocentric Coordinate Time (TCG) are currentlly in use for space travel purposes. And each is tied to 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), however, the former TCB "performs exactly the same movements as the Solar system but is outside the system's gravity well" and the later TCG "performs exactly the same movements as the Earth but is outside the Earth's gravity well". And since the second is about the length of a single heartbeat, I say we should stick with that definition....as long as we're still human...for artifical intelligence: yeah I don't know...maybe they'll still use the caesium atom since it's orbital period is so stable. Oh, and TAI also doesn't account for leap seconds. And by applying a year base of 0, the terran computational calendar doesn't account for them either.

So there you go sir, the scientists beat you to it 37 years ago.

I found this comment to be interesting. It describes how a timestamp could be separated metrically into secs, ksecs (00:16:40), msecs (about 11.6 days), gsec (about 31.7 years). So a UNIX timestamp of 1401510007 could be written as 1:401:510:007 and you'd have a close idea of what time it is...if you're used to it, I guess.

Yeah, I love ISO 8601 too: it's easy to use because it's standardized. But extremely strict standards arent always the best in every situation.

Besides the fact that the terran computational calendar's time of day is often in sync with UTC and that TC can account for UTC's IERS issued leap seconds, it has little else to do with UTC and a lot to do with the 1977 TAI redefinition (TAI = International Atomic Clock). UTC works well for dates after 1977, but exact dates before that are iffy especially before 1972 when leap seconds were treated differently. In addition to that, UTC makes it a little hard to work with leap seconds when it comes to UTC. I haven't created an complete implementation of UTC myself, and I wouldn't want to. The terran computational algorithm is relatively simple to implement, even with it's dynamics.

Standardizing the terran computational calendar would be much easier than standardizing UTC, but we all know that's it's adoption on any grand scale any time soon is unrealistic. But... I'm not convinced that grandscale adoption is really it's true purpose.

Solstice:
The first day of the terran computational calendar contains the northern winter solstice. But you're correct, it makes no claims of "always being synchronized exactly"...in order to do that for this calendar, it would take some heavy erratic leap duration modification, so: not an option. However, the seasons do seem fall on specific days plus or minus. There's a section on the website explaining how the seasons won't always occur at the same time and it provides a comparison table between proximal gregorian dates and terran computational dates for the four seasons.

My apologies : http://terrancalendar.com/#roughly: basically this is there to make people aware that TAI was redefined in 1977 (and UTC too in 1972 AFTER the UNIX Epoch!), and since the calendar is defined in terms of this definition, the UNIX Epoch is off by certain number certain number of milliseconds. Hence the term 'roughly;. And depending on how it's implemented and who you talk to about how it's defined, the UNIX Epoch has all sorts of definitions, which is why it would be silly to base an official calendar definition on it.

Months:
That's cool. Personally I like the simplicity of standardized units and I'm still happy that the 28 day month is still in between the sideral (~27.3) and synodic (~29.5) periods of the moon.

The only reason for this is that it works. Omitting a leap day every 128 years was not chosen because it was a power of 2, but because it is literally THE MOST EFFICIENT METHOD that exists to keep a year synchronized with the same point, and also the most simplistic when it comes to working it into an algorithm. Having a simple, accurate, efficient "computational" algorthim is what this calendar is all about.

Leap Seconds: The terran computational calendar kicks ass when it comes to leap seconds and leap duration.
* All leap duration is stardardized by being put at the end of the year into a 'minimonth'
* Don't want to account for ANY leap seconds? Apply a year base of 0
* Only want to account for leap seconds before a year n? Apply a year base of n
* Want to write a future date without knowledge of future erratic leap duration (like leap seconds)? Apply a year base less than or equal to the current year to your future date.

zero-based numbering:
Insisting on "zero-based numbering" solves many things. Ease of calculation for starters. What's 2 months 20 days plus 3 months 18 days? 6 months 10 days. Much simpler than ohter methods. Zero-based numbering doesn't do all that much for some calendars but it definitely thrives with this one.
Besides, everybody is familiar with our current system's zero-based (24hour clock) hours, minutes, and seconds any ways, so why not the rest of the date units, right?

And every week is a TwoDays

Thats not true for ther terran computational calendar though. That's only the case with things like perpertual calendars that implement leap weeks instead of leap days.

The terran computational calendar implements leap days not leap weeks. So depending on how you define weeks.....

But here's an interesting thought: your terran computational birthday won't always be on the same day as your gregorian one! Adopt two calendars and get two birthdays: It's a win win.