A new calendar system
Today (as I write this) is 653.2006. That's Tuesday 28 November 2006 for you Gregorians out there.
Before explaining why today is 653., let's see the motivation for a new date system: months and weeks.
About months: the idea of a large group of days forming a regular pace at which to pay bills and receive paychecks is fine by me. What's wrong with our current Gregorian months is simply that they are archaic, unnatural, unwieldy motley relics of millennia past.
About weeks: compared to months, weeks are great. They are always the same length. They give us a convenient and universal way of dividing our days into work and non-work. They help us decide when to plan our vacations, holidays, weddings - basically everything.
Have you ever noticed that it's not so easy to perform computations with hours, minutes, and seconds? For example, quickly find exactly how many hours:minutes:seconds elapsed between 11:51:43 am and 2:41:20 pm today? You can do it if you try (2:49:37), but it would be a lot simpler if we simply used a purely decimal system (e.g. 14.689 - 11.862). The challenge is that we're using a mixed-base representation here. Really, it's a strange combination of base-10 numerals within a base-60 system - a vestige of the Babylonians, those crazy guys.
What could be worse than a base-10 notation within a base-60 arithmetic? How about a base-10 date within a base-?!@# month system, where ?!@# is either 28, 29, 30, or 31 depending on where you are in the world, your religion, which year it is, and how far into that year you are. Yes, that makes perfect sense. (I mention location and religion as a reference to those who for hundreds of years used the Julian calendar; of course there's also many lunar calendars and others as well!)
In other words, 1 January 2007 will be 1.2007. Next is 2.2007 and counting up until we get to 7 January, which is denoted 10.2007. Continuing, 14 January is 20.2007 and 21 January is 30.2007. The idea is that each time a digit would normally (in base 10) become a 7, in base 7 it becomes a 10. This is a well-known idea to mathematicians; in fact, since you already know how to think base-60 (and base-12 or -24 for hours of the day), it shouldn't be hard to grok for base 7 as well. Here are a few more example conversions:
First: we may now consider each 49-day period as a new kind of month. This is very easy in the new system since days 0. - 66. are the first month, followed by 100.-166., then 200.-266., etc. In other words, the third digit from the . indicates the current "month". At the end of the year is a half-month of either 22 or 23 days depending on leap years.
The new system is independent of how you choose to track your years. It would be best for everyone to agree on a single, elegant and easy-to-use system, but historically that is a colossal task. Leap years and the length of years in general are topics for another post.
Second: All of the same days of a week end in the same digit. For example, because today, 653., is a Tuesday, I also know that 3. (3rd of January) was a Tuesday and that 665. (7 December) will be a Thursday.
In fact, if this system were to be widely adopted, then we could coordinate all 1's (dates ending in 1) to be Saturdays, 2's to be Sunday's, etc. Thus computing the day-of-year of any date in any year would be trivial (even some monkeys could do it). Furthermore, holidays which we prefer to stay on a certain day of the week will remain the same date year-to-year. No more X falls on the 6th Wednesday of Frebtober. The cost of this adoption would be a slight discontinuity at the end of every year. However, keep in mind that this "discontinuity" translates to "three-day weekend" every non-leap year and "four-day weekend" every leap year (this may be one of the strongest selling points here).
I've been using the system for my own personal records for a couple years now. It is tricky at first, mostly because no one else has even heard of it (so far). It is also difficult to buy calendars in this new system. However, a while ago I put together a little php page to display the calendar year in this system. Back then I was a little less modest and had called the system the "tdate". Here is the php calendar. [landscape-printable version]
Before explaining why today is 653., let's see the motivation for a new date system: months and weeks.
About months: the idea of a large group of days forming a regular pace at which to pay bills and receive paychecks is fine by me. What's wrong with our current Gregorian months is simply that they are archaic, unnatural, unwieldy motley relics of millennia past.
About weeks: compared to months, weeks are great. They are always the same length. They give us a convenient and universal way of dividing our days into work and non-work. They help us decide when to plan our vacations, holidays, weddings - basically everything.
Have you ever noticed that it's not so easy to perform computations with hours, minutes, and seconds? For example, quickly find exactly how many hours:minutes:seconds elapsed between 11:51:43 am and 2:41:20 pm today? You can do it if you try (2:49:37), but it would be a lot simpler if we simply used a purely decimal system (e.g. 14.689 - 11.862). The challenge is that we're using a mixed-base representation here. Really, it's a strange combination of base-10 numerals within a base-60 system - a vestige of the Babylonians, those crazy guys.
What could be worse than a base-10 notation within a base-60 arithmetic? How about a base-10 date within a base-?!@# month system, where ?!@# is either 28, 29, 30, or 31 depending on where you are in the world, your religion, which year it is, and how far into that year you are. Yes, that makes perfect sense. (I mention location and religion as a reference to those who for hundreds of years used the Julian calendar; of course there's also many lunar calendars and others as well!)
Here is the proposed system of numbering days: each day is simply notated "day.year" (or simply "day.") where "day" is the number of days since the previous year in base 7. |
In other words, 1 January 2007 will be 1.2007. Next is 2.2007 and counting up until we get to 7 January, which is denoted 10.2007. Continuing, 14 January is 20.2007 and 21 January is 30.2007. The idea is that each time a digit would normally (in base 10) become a 7, in base 7 it becomes a 10. This is a well-known idea to mathematicians; in fact, since you already know how to think base-60 (and base-12 or -24 for hours of the day), it shouldn't be hard to grok for base 7 as well. Here are a few more example conversions:
| Gregorian date | Day of year | base 7 |
|---|---|---|
| 28 January | 28 | 40. |
| 31 January | 31 | 43. |
| 1 February | 32 | 44. |
| 28 November | 332/333 | 653./654. |
First: we may now consider each 49-day period as a new kind of month. This is very easy in the new system since days 0. - 66. are the first month, followed by 100.-166., then 200.-266., etc. In other words, the third digit from the . indicates the current "month". At the end of the year is a half-month of either 22 or 23 days depending on leap years.
The new system is independent of how you choose to track your years. It would be best for everyone to agree on a single, elegant and easy-to-use system, but historically that is a colossal task. Leap years and the length of years in general are topics for another post.
Second: All of the same days of a week end in the same digit. For example, because today, 653., is a Tuesday, I also know that 3. (3rd of January) was a Tuesday and that 665. (7 December) will be a Thursday.
In fact, if this system were to be widely adopted, then we could coordinate all 1's (dates ending in 1) to be Saturdays, 2's to be Sunday's, etc. Thus computing the day-of-year of any date in any year would be trivial (even some monkeys could do it). Furthermore, holidays which we prefer to stay on a certain day of the week will remain the same date year-to-year. No more X falls on the 6th Wednesday of Frebtober. The cost of this adoption would be a slight discontinuity at the end of every year. However, keep in mind that this "discontinuity" translates to "three-day weekend" every non-leap year and "four-day weekend" every leap year (this may be one of the strongest selling points here).
I've been using the system for my own personal records for a couple years now. It is tricky at first, mostly because no one else has even heard of it (so far). It is also difficult to buy calendars in this new system. However, a while ago I put together a little php page to display the calendar year in this system. Back then I was a little less modest and had called the system the "tdate". Here is the php calendar. [landscape-printable version]
posted by Tyler | 5:22 AM
3 Comments:
miley cyrus nude [url=http://www.ipetitions.com/petition/mileycyrus]miley cyrus nude[/url] paris hilton nude [url=http://www.ipetitions.com/petition/parishilt]paris hilton nude[/url] kim kardashian nude [url=http://www.ipetitions.com/petition/kimkardashian45]kim kardashian nude[/url] kim kardashian nude [url=http://www.ipetitions.com/petition/celebst]kim kardashian nude[/url]
I have just devised pretty much the same system - then I googled "base 7 calendar" and found your page!
How do you deal with the 22.25 days left over at the end of the year?
it's difficult to imagine a new calendar system on a base 7 , especially one starting on January 1, which is an artificial time to start a calendar. Preferably it should begin with the spring vernal equinox, currently April 21. it appears to me that one cannot also ignore the solar cycle nor the lunar cycle, which is only based on multiples of 12 because of the historical use. But from a mathematical consistency model perspective, good work. I'm working on a base 10 model with months of 36 days with 4 weeks of 9 days. This would only require one half day added at end of year to make 365.5; the day would only have 10 hours, 4 hours of work, 3 hours of rest, study, or recreation, and 3 hours of sleep.
Post a Comment
<< Home