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.
Whose ephemeris?
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.
leap days (one most years and two every 4th but not 128th year)
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?
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.
"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.
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." - wikipediaofficial 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
Slashdot Mirror
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.
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.
Whose ephemeris?
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.
leap days (one most years and two every 4th but not 128th year)
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.
"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