CALENDAR REFORM

The Gregorian calendar we currently use is very badly designed. It features months of uneven lengths, varying between 28 and 31 days, which are rather stupidly named. Ever noticed that September, October, November and December start with 'sept', 'oct', 'nov' and 'dec', which are Latin for 7, 8, 9 and 10? Thats because their names are sourced from the Roman calendar, which only contained 10 months, and in which March was the first month. This made September the 7th month, October the 8th month, and so on. Their names used to make sense, but now they don't.

On top of this, the length of the year at either 365 or 366 days long does not divide well into 7. The standard accepted length of a year in weeks is 52, but a year with exactly 52 weeks gives us only 364 days, slightly short of the target. For this reason, the start of the year is constantly shifting.

If I were to ask you what days this year April 9th, August 27th and December 5th were, would you be able to answer without looking it up? Probably not. Even if you managed to figure it out for this year, it breaks for next year.

We must be able to do better.

Introducing the 13 month calendar

In this calendar, each year consists of 13 months, with each month containing exactly 4 weeks or 28 days. Because the length of each month is an exact number of weeks, every month starts on the same day. For the sake of argument, let's say it will be Monday (because this is the standard accepted first day of the week everywhere outside of the US). This means that January 1st is a Monday. February 1st is a Monday. March 1st is a Monday. Every single month is completely identical. In fact, every single year is also completely identical.

No longer will you have to guess or look up what day December 5th will be. The 5th will ALWAYS be on a Friday. Likewise, if someone asks you what you're doing on the 18th, you immediately know that's a Thursday. And for superstituous people out there, Friday 13th also becomes a thing of the past, because the 13th is always on a Saturday. :P

While this sounds pretty cool, the biggest problem you will realise in this proposal is that we are at least 1 day short. 13 months of 28 days only gives us a 364-day year. If we want to stay in alignment with the seasons without any shifting, we need to be averaging 365.2425 days per year. Because of this we will have to add at least 1 extra day. Fortunately, this does not cause a significant issue to the new calendar.

For almost everyone, the rollover of the new year is a celebratory day and treated differently to many others. We continue this long standing tradition by adding New Years Eve as an additional day. This day follows the 28th day of the last month and is simply written as (for example) "New Years Eve 2018". In order to avoid breaking the consistency of the months and years, we do not assign it any specific date number or weekday, and simply shorthand it to NYE 2018. This means we would have Saturday 27th, Sunday 28th, New Years Eve, then Monday 1st.

For leap years, we keep the current Gregorian system (inserting a leap year every 4 years, except when divisible by 100 but not 400) and insert an extra day before New Years Eve. Thus, for leap years, we would have Saturday 27th, Sunday 28th, Leap Day, New Years Eve, then Monday 1st.

(For programming purposes, we can store the extra dates as the 29th and 30th of month 13 if needed.)

Below is a demonstration of the calendar how it would look under this system.

MONTH 1
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 2
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 3
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 4
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 5
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 6
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 7
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 8
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 9
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 10
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 11
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 12
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
MONTH 13
MTuWThFSaSu
1234567
891011121314
15161718192021
22232425262728
EXTRA DAYS
LEAPNYE

See how consistent this calendar is?

Naming the months

We have various options for naming the months. We could name them based on the existing names, although we need to add a 13th month name to do this. One commonly suggested option is to name the 13th month "Undecimber", which is Latin for 11th month and logically follows December, but this seems a bit ungainly to me, especially since it reinforces our already-illogical month naming convention. Another suggested option is to name the extra month "Sol" and insert it between June and July. A third possibility is to drop the stupidly named months entirely, and instead go with something like Zodiac signs for months instead (because most people already know what they are). The extra month being added in that case would be Ophiuchus, which goes between Scorpio and Sagittarius.

Any of these options are technically fine. For sake of future discussion we will use the second suggestion (inserting Sol between June and July) because this is the option most generally accepted (although it's not my personal favourite - I prefer the Zodiac naming).

Festivals and celebrations

I got asked a bunch of times what would happen to the dates of festivals and celebrations, such as birthdays. This is fairly easy. Simply determine the date in which your birthday would have been held if we had used the reformed calendar at the time, and use that as the new date. For example, my birthday is September 11th. The year I was born in was not a leap year, so I was born on the 254th day of the year. In the 13-month calendar where the extra month is Sol, the 254th day of the year would be Tuesday 2nd September. So, after calendar reform, my birthday would always be on Tuesday 2nd September. Because the date of birth should always be specified with the year included this should not cause any ambiguity if the date needs to be converted back to the Gregorian calendar later (although it may lead to some people celebrating their birthday during leap years with a one-day offset in comparison to before, as the leap day is inserted at a different point in the year in the 13-month calendar).

For celebrations, consider for example Christmas Day, which is normally held on the 359th day of the year (currently December 25th). This would become Tuesday 23rd December in the new calendar. With enough consensus, it is plausible that we could move it to the closest weekend, e.g. Sunday 21st December. As long as everyone agreed to this as part of the calendar reform there should be no issue.

Quarters

Businesses like to do profit calculations in quarters amongst other things. Very simply, in this calendar, a quarter is 13 weeks. The first quarter therefore ends on April 7th, the second on Sol 14th, the third on September 21st, and the fourth on New Years Eve. Easy.

Reformed calendar demo

This simple Javascript-based demo shows the current date and time in both Gregorian and 13 Month calendars using Sol as the extra month. A variation based on Zodiac sign months is also shown. In both examples, the start of the week is Monday.

loading...

Why this calendar will never see the light of day

This calendar reform has been suggested before. It first saw the light as the 'Positivist Calendar' proposed by the French philosopher Auguste Comte in 1849. Later, it was proposed again in 1902 by Moses Cotsworth, who called it the 'International Fixed Calendar', although his version had some minor differences to the one proposed above (the leap day was inserted at the end of June, the last day of the year was called Year Day, and the first day of each month was a Sunday). The version favoured by Cotsworth was used by Kodak for business purposes for decades, and even managed to get as far as a League of Nations committee in the 1920s, who highlighted it as the best calendar reform proposal out of 130 that were suggested.

Unfortunately, this calendar proposal drew the ire of religious people, especially those from the US, who insisted that they MUST pray every 7 days, and that if additional days were inserted into the calendar which interrupted the normal flow of the week their day of prayer would go out of sync with the working week. For primarily this reason, the reform was dropped.

Consequently, to this day, we still have a crappy calendar, and due to the widespread introduction of computers, the likelihood of us ever reforming the calendar again is probably very slim.

Avoiding religious complaints

To avoid religious complaints with this calendar and preserve the start day of Monday each year, it is necessary to remove the added days, turning the year into a 364-day year. You might not find this to be a huge deal, but the calendar would slowly drift out of sequence with the seasons. Over a 400-year time span, we would have 20800 weeks instead of 20871, which makes us 71 weeks short. The drift would probably be noticeable even within human lifetimes. It would get so bad that after several hundred years winter in the northern hemisphere would fall in the middle of July. Obviously we have to make up for this shortfall.

To counter this problem, we MUST insert leap days. But, because each year must also start on a Monday, we can only insert multiples of 7 days at a time. This gives us the concept of a 'leap week', of which we need to insert 71 over every 400-year period.

Aside from moving the first day of the year to break alignment with the Gregorian calendar, the leap week proposal turns birthdays and anniversaries of leap week dates into hell, as you can't easily just offset those leap week dates by a single day like you can with the standard leap day. A small religious-favouring minority who also favour the 13-month calendar have tried to push for a leap week calendar, but both of these issues make it an unfavourable proposal.

To be honest, I hate this workaround, and so does pretty much everyone else, which is the main reason this reform died. But for the sake of covering the entire topic, below you can see several options for inserting leap weeks.

The Thursday Rule

One method to produce 71 leap weeks every 400 years is to make leap years any years where the Gregorian calendar would begin or end on a Thursday, because there are 71 of these every 400 years. With this method, the start of the year would vary from the Gregorian calendar by no more than 3 days at any time.

To give you an example of how this would work, the following years between 2000 and 2400 would become the new leap years for that period:

2004, 2009, 2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088, 2093, 2099, 2105, 2111, 2116, 2122, 2128, 2133, 2139, 2144, 2150, 2156, 2161, 2167, 2172, 2178, 2184, 2189, 2195, 2201, 2207, 2212, 2218, 2224, 2229, 2235, 2240, 2246, 2252, 2257, 2263, 2268, 2274, 2280, 2285, 2291, 2296, 2303, 2308, 2314, 2320, 2325, 2331, 2336, 2342, 2348, 2353, 2359, 2364, 2370, 2376, 2381, 2387, 2392, 2398

This is a repeating pattern every 400 years. The next leap years would be 2404, 2409, 2415, etc.

As you can see, the distance between leap years varies, with leap years being between 5 and 7 years apart. This is extremely impractical. Nobody would be able to easily determine which years were leap years.

The 5:40:400 Rule

Currently, leap years are divisible by 4, but not 100 (unless also divisible by 400). We can design a very similar leap year rule to give us 71 leap years - make leap years divisible by 5, but not 40 (unless also divisible by 400). This gives you a pretty easy pattern:

2000, 2005, 2010, 2015, 2020, 2025, 2030, 2035, 2045, 2050, 2055 ...

While easy to understand and memorize, this has the slight disadvantage that the start of the year would drift by up to 11 days early and up to 6 days late. However, over the long-term, the seasons would be largely preserved.