Slashdot Mirror

Nope. I see what you're saying, but the whole world uses UTC for basically everything whether you like it or not. Maybe you meant ISO 8601, which is a standardization of UTC? Leap seconds are issued for UTC, nothing else, so if you look down at your cellphone and it says 03:10:30 PM : That's UTC time, not TAI time, not UNIX time: UTC time. If it were TAI it would read: 03:10:55 PM, but TAI is not used for most everyday purposes. Just informing you....

The point I was attempting to make earlier was that the terran computational calendar is easy to understand and adopt (It's algorithm for standard dating is much simpler than most), it can be further standardized if need be for specific purposes (it even has a public domain mark), it has dynamic support for timezones through the use of datemods (PST is a UTC -08:00 offset and a +8H datemod), and all calendars have a designator associated with them: AD & BC, CE & BCE, UTC & TAI, and TC (which stands for terran computational). Through the use of acceptable delimiters:
space, plus, comma, minus, dot, slash, colon, underscore ( +,-./:_)
you can write dates however you see fit or would like to standardize them further as long as you use those delimiter and follow some basic parsing rules:
44-5-22 6:23:57 TC == 44.5.22,6.23.57 TC == 44.5.22_TC.6H23M57 == 44.5.21,23.23.57 TC+7H == 44/5/21 23:23:57 TC+7H

Nope. I see what you're saying, but the whole world uses UTC for basically everything whether you like it or not. Maybe you meant ISO 8601, which is a standardization of UTC? Leap seconds are issued for UTC, nothing else, so if you look down at your cellphone and it says 03:10:30 PM : That's UTC time, not TAI time, not UNIX time: UTC time. If it were TAI it would read: 03:10:55 PM, but TAI is not used for most everyday purposes. Just informing you....

The point I was attempting to make earlier was that the terran computational calendar is easy to understand and adopt (It's algorithm for standard dating is much simpler than most), it can be further standardized if need be for specific purposes (it even has a public domain mark), it has dynamic support for timezones through the use of datemods (PST is a UTC -08:00 offset and a +8H datemod), and all calendars have a designator associated with them: AD & BC, CE & BCE, UTC & TAI, and TC (which stands for terran computational). Through the use of acceptable delimiters:
space, plus, comma, minus, dot, slash, colon, underscore ( +,-./:_)
you can write dates however you see fit or would like to standardize them further as long as you use those delimiter and follow some basic parsing rules:
44-5-22 6:23:57 TC == 44.5.22,6.23.57 TC == 44.5.22_TC.6H23M57 == 44.5.21,23.23.57 TC+7H == 44/5/21 23:23:57 TC+7H

Wow, I'm definitely taking that as a compliment. I'm honored that you thought I was a doctoral candidate, but I actually consider myself an organic gardener who has a computer science degree and some interest in calendrics, but hey, if you want to try and brand me as a doctoral student, then please, go right ahead....

I offer ideas, nothing more. The terran computaional calendar contains a public domain mark, which basically means that it's completely free of copyright. This means that, any person or group has the option to use or modify its ideas as they see fit for their own implementation without worrying about copyright or referencing where those ideas came from.

Well, if you count 'minimonth', then there's actually 14.

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.

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.

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.

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.

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?

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?

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?

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.

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

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.

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.

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.

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.

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'.

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

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

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)

And if you use Steven Wright's calendar, you can ignore sevens.

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)

And if you use Steven Wright's calendar, you can ignore sevens.

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)

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)