Forgot your password?
typodupeerror

Comment: Re:yeah, this is an improvement (Score 1) 209

Very interesting, thank you. You seem to be well versed in calendrics.

This source seems to suggest that the January 1st was a 'political compromise':

According to Kevin Tobin Julius Caesar wanted to start the year on the vernal equinox or the winter solstice, but the Senate, which traditionally took office on January 1st, the start of the Roman civil calendar year, wanted to keep January 1st as the start of the year, and Caesar yielded in a political compromise.

So our current calendar isn't really synchronized with anything: just when some ancient Roman big whigs got together every year. So, that's definitely not fit for the terran computational calendar start date.

As for the equinox, what year do you think we should sync that to? I'll see how that might work with terran computational algorithm....:
vernal equinox 1970: 6825600 seconds (79 days) after the UNIX Epoch.
Hmmm... not as round as -10 days, but maybe... What about 1977?
vernal equinox 1977: 228528000 TAI seconds (2645 TAI days) after the UNIX Epoch & 88 days after the 1977 TAI redefinition... easy to remember I guess. But then, how would leap seconds be handled? If they aren't handled then the day slowly drifts from midnight losing a full hour after about 4-5000 years (which is a pretty long time, so maybe leap seconds shouldn't really be accounted for). And maybe the terran computational calendar should simply keep in sync with TAI and then define year bases in some other way to handle leap seconds?

Calendar Epochs, in my opinion, are the most difficult things to pick when designing a calendar. I've had tons of trouble with it over the years.

And, as far as the beginning of units goes, I still like the thought of them changing when everything is in it's most dormant state.

Can you or anyone think of any other neutral accurately measurable Epochs?

Comment: Re:Thirteen months, who's on crack? (Score 1) 209

Interesting, thank you. This source suggests, however, that ancient calendars may have tracked the position of the moon in the sky instead of it's phases, which would mean that there would have been 13+ moons per year:

However, besides keeping track of time through the phases of the Moon, one can also keep track of time by the path the Moon takes through the sky. Using the course of the Moon to keep track of time results in using what modern astronomers call a sideral month, which is 27 days 7 hours and 43 minutes long. Every 27 days the moon returns to the same position in the sky it was 27 days before. The scholar Vaster Guðmundsson believed that this was the form of month the Norse used, and used it in his theoretical reconstruction of the ancient Scandinavian calendar (Guðmundsson 1924, p.88). It is possible then that the Anglo-Saxons also did the same. However, as Bede draws a comparison to the Greek and Hebrew calendars, we may want to assume that the Anglo-Saxons used a synodic month (a month measured from a phase of the Moon to the next time that phase of the Moon occurs). There are other clues in Bede's account, that indicate this was so, and I will touch on those later. Bede then goes on to name the months of the old Anglo-Saxon calendar and further gives the corresponding Roman month.

Comment: Re:Obligatory griping (Score 1) 209

Yeah, as I got more into it, I realized that zero-based time keeping is really the way to go. The initial archaic descendant of the terran computational calendar (which I named the 13 moons calendar) only used zero bases for years, hours, minutes, seconds, and it eventually dawned on me that so many things on multiple levels would be so much easier if every unit was zero-based, hence it's current inception. The only (but still very valid) reasons not to use zero-basing is convention and ordinal numbering (0th, 1st, 2nd, 3rd), which can be confusing, which is why I like to stress that using ordinal numbering is discouraged when dealing with zero-based calendars. Quote from an above comment #47139161:

So just treat years, months, and days as you would hours minutes and seconds in a 24-hour clock. I've also been doing some thinking about how to represent specific durations and placement like "month 2 day 3 of each year" could be written by appending an M to the designator meaning that the first unit represents months and the duration is equal to the last unit (in each unit equal to the one [that general precedes] the first unit, in this case 'each year'). So "month 2 day 3 of each year" becomes 2.3TCM. And as for [another example,] "day 0 of each month" becomes 0TCD

Oh!, and you asked:

When did you turn 1 year old?

I have a vietnmese friend who said that his culture accepts that you're already 1 year old when you're born because of the (general) amount of time spent in the womb.

Comment: Re:It's like Swatch .beat Internet time all over (Score 1) 209

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

Comment: Re:intricacy can allow for simplicity (Score 1) 209

I wrote this in a different comment:

Quarters and Weeks within a terran computational date are not officially defined or supported, they are only accomodated through datemods. It's up to individuals/groups to create any further definitions of what a quarter or week may be for their own purposes.

This calendar does not track the moon, or all seasons, it only tracks days and the year (which always falls within a day or two of the n. winter solstice). As for quarters, these are useful for business and industry and it's pretty easy to remember their dates since they're all 3 months and 1 week:
44TC+0Q = 44.0.0 TC
44TC+1Q = 44.3.7 TC
44TC+2Q = 44.6.14 TC
44TC+3Q = 44.9.21 TC
44TC+4Q = 44.13.0 TC

+4Q probably shouldn't be used for businesses [but they should just instead] include 'minimonth' in the last quarter, but that's not in the scope of the terran computational algorithm.

Comment: Re:No one cares about your shitty dissertation (Score 1) 209

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.

Comment: Re:Obligatory griping (Score 1) 209

Which is why I raised doubts that a computer would be programmed to do it correctly to begin with (it will only be on the minds of programmers near that 128-year threshold), and doubts that it would be remembered at all ("Just let the machine do it").

True, but I would hope that future programmers would realize (somehow) that a year isn't exactly 365.25 days.

Only if you ignore your epagomenal days. Food and fuel must still be consumed, rent must still be paid, and interest must still be accrued. Your perpetual quarters are actually 91.310 546 875 days exactly.

Quarters and Weeks within a terran computational date are not officially defined or supported, they are only accomodated through datemods. It's up to individuals/groups to create any further definitions of what a quarter or week may be.

Of dubious value, as tropical seasons are not of equal (or uniform) length, and the beginning and ending dates of your quarters will be non-obvious.

Correct. This calendar does not track the moon, or all seasons, it only tracks the year (n. winter solstice) and the day. As for quarters, these are useful for business and industry and it's pretty easy to remember their dates since they're all 3 months and 1 week:
44TC+0Q = 44.0.0 TC
44TC+1Q = 44.3.7 TC
44TC+2Q = 44.6.14 TC
44TC+3Q = 44.9.21 TC
44TC+4Q = 44.13.0 TC

+4Q probably shouldn't be used for businesses though which should probably just include 'minimonth' in the last quarter, but that's not in the scope of the terran computational algorithm.

But the relationship between cardinal and ordinal dates will become ambiguous.

Ordinal numbering is not recommended for the terran computational calendar. Also ever verbose language that doesn't use the TC designator is discouraged. I talk about further:

Every single law and contract mentioning "the first of the month" will need to be rewritten to be unambiguous, since "1st day of the month" and "day 1" will be two different days.

Not exactly, if there isn't a TC designator appended to it, then it isn't a terran computational date. Ordinal numbering is not recommended for the terran computational calendar. So just treat years, months, and days as you would hours minutes and seconds in a 24-hour clock. I've also been doing some thinking about how to represent specific durations and placement like "month 2 day 3 of each year" could be written by appending an M to the designator meaning that the first unit represents months and the duration is equal to the last unit (in each unit equal to the one about the first unit, in this case 'each year'). So "month 2 day 3 of each year" becomes 2.3TCM. And as for your example "1st day of the month" would be "day 0 of each month" becomes 0TCD

There is no such thing as a perpetual calendar. Comparisons between algorithms of intercalary days can only be valid for about one millennium from now. Even the current standard of leap seconds itself (which allows for up to 12 adjustments per year) will break down around then.

True. But omitting leap days every 128 is extremely efficient. Also the current 'minimonth' offers support for up to 27 leap days plus 24*60*60 = 86400 leap seconds per year.

midnight:
The terran computational calendar does not define midnight. That's up to the philosophers I guess. However midnight between years 43 and 44 may be expressed as 44TC, 44.0.0TC, or 44-0-0 0:0:0TC, because all terran computational dates represent precise instances in time.

Comment: Re: One more reason to get off this rock (Score 1) 209

So are you saying that you don't believe in relativity and, therefore, gravometric distortion? Those cleaver little scientists do there best to average the atomic clocks out ( by taking into account their altitudes and what not) resulting in an algorithm that spits out the number of SI caesium seconds measured at mean sea level.

Comment: Re: yeah, this is an improvement (Score 1) 209

Yes, it could applications in science and industry for sure.
It has the option of being a little complicated if you need it to be, but it definitely doesn't have to be. Would you say that 44-5-21 16:51:5 TC+7H is complicated? Or just that it would be hard for people in general to get used to because we're so used to our current system. And in that case, that's true about switching bewteen any calendar (which is still always a valid point).

Comment: Re:yeah, this is an improvement (Score 1) 209

Oops! My bad. The converter is fixed now . Had to use javascript's getUTCFullYear instead of getFullYear. It apparently makes a difference when months and days are at their origin like your 2014-01-01 0:0:0 example. Thanks for reporting the bug! Here's a jsfiddle to demonstrate the difference.

Lunas: Yeah, that might be a good idea. However, I think naming them 'Lunas' might give people the impression that this is a lunar calendar, and that would be bad because it definitely doesn't accurately tract the cycles of the moon in any way shape or form. The calendar currently only uses the term Luna in the datemod section in order to define L = 28 days because M = 60 seconds. Hmmm... Good thought though.

Choice of year schronization:
seasons: I've heard people say that the equinox is a more stable constant so it definitely has that going for it. The solstice was chosen because it is the darkest point (but only in the northern hemisphere). The new moon is at the darkest point and so is the day. I'm not completely convinced that the terran computational calendar should break with that standard, but maybe, the equinox would definitely be a more neutral location. But if we are staying on the side of neutrality then which equinox?
january 1: If you're going to create a whole new calendar, I feel like keeping with a January 1st start date would be very confusing because you might expect the date to be a UTC date when it's totally not at all the same. But there'd be lots of confusion in ANY case. I know that TAI/UTC/UNIX uses January 1st, but besides that, do you know of any good reason to use January 1st as a start date other than convention?

Thanks again.

If God had a beard, he'd be a UNIX programmer.

Working...