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?
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.
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.
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
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.
What do you think would be a good epoch for a calendar and why?
Do you like the gregorian's January 1st? starting 2013+ years ago? Why?
northern vernal equniox? and if so, why not the southern vernal equinox?
What would you want from a calendar?
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.
Sure, and not to confuse the point, from POSIX Time aka UNIX Time:
"Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC"
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.
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.
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).
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?
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.
Slashdot Mirror
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?
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.
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.
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
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.
What do you think would be a good epoch for a calendar and why?
Do you like the gregorian's January 1st? starting 2013+ years ago? Why?
northern vernal equniox? and if so, why not the southern vernal equinox?
What would you want from a calendar?
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.
True, but 44TC+2Q can be easily parsed and it's definitely shorter than "by 2Q of 44 UTC"
Well, if you count 'minimonth', then there's actually 14.
calculate the amount of time that occured since the beginning of the year
We can already do that.
Yes, of course you can, but the algorithm to do so is definitely much more complex than that of the terran computational calendar's.
Sure, and not to confuse the point, from POSIX Time aka UNIX Time:
"Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC"
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.
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.
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).
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.
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.
.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 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
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.