The Basics

• Perennial (fixed layout) solar calendar
• 13 months per year
• 4 equal quarters, or “seasons”, per year
• 4 weeks per month
• 7 days per week (except “sync days” - more on them later)
• No weekday names
• All weeks, months, and years start with the same weekday
• Every year and month has the same layout
• Years start with “March”
• The new 13^th month is added at the end, after February, and called Addenduary
• New Year is closely aligned with the northward equinox (March equinox)
• Holocene/Human Era (HE) years (Gregorian + 10’000)
• Years are written with a millennium indicator letter (more on that later)
  • So the Gregorian year 2026 would be 12’026 (with the millennium indicator written as M026)
• No negative years (or AD, BC, etc.)

Month layout

You probably already saw it on the home page. This is what the calendar layout looks like:

But there is a catch, right?

Kind of. Because 28 days × 13 months is only 364 days, we are missing a day in a common year and two days in a leap year to get to 365 and 366, respectively. To fix that discrepancy SAC13 uses synchronization days (or sync days for short) to keep the calendar in sync with Earth’s motion around the sun.

Sync days are, unlike in other 13-month calendar proposals, not unnamed “blank” days but are part of a specific week, month and quarter, and have regular ordinals like all the other dates. If there is a sync day, it’s added to the end of the month as the 29^th, and it belongs to the last week of that month. Those eight day weeks are called long weeks or sync weeks and have a three day weekend.

• Every year ends with a sync day:
  29^th Addenduary

• On leap years, August has a sync day too:
  29^th August

It’s fair game to call them Year Day and Leap Day if you want, but keep in mind that it’s similar to calling 14^th February Valentine’s Day. Other people probably know which day you mean, but those are not formally recognized names for the day.

Year layout

Here is the entire layout for a year, including the sync days. The sync day in August, shown with a dashed line, is only present in leap years.

Leap years

Every four or five years SAC13 has a leap year to ensure that the start of the year stays close to the March equinox. This is done algorithmically - not through observation - as follows:

1. Take the year and add 199
2. Divide that by 293 and continue with the remainder (mod 293)
3. Divide that by 33 and continue with the remainder (mod 33)
4. Divide that by 4 and continue with the remainder (mod 4)
5. If the result is 1 it’s a leap year

Why those exact magic numbers, technical details, and why I think it’s okay that you can’t do that in your head here.

In most programming languages the implementation is a branchless one-liner:

fn is_leap_year (year: u32) -> bool
{
    (year + 199) % 293 % 33 % 4 == 1
}

No weekday names

SAC13 doesn’t have official names for the weekdays but formally recognizes only weekday ordinals like “1^st weekday”, “2^nd weekday”, and so on. Because all months have a fixed layout, the day of the week is completely determined by the day of the month.

To determine the day of the week in SAC13 for any day, find the previous multiple of seven and take the difference. For example to find the day of the week for the 24^th, find the last multiple of seven (21^st), take the difference (3), so it’s the 3^rd day of the week, “Weekday Three” or “D3”. Note however, this does not tell you the Gregorian Calendar day of the week.

It’s important that you don’t use “Monday” instead of “D1” - those are not synonyms. If you use SAC13 and the Gregorian Calendar in parallel, you can, of course, use “Monday” - but only if that date really is a Monday on the Gregorian Calendar.

Do you want more details on SAC13 weekdays and why they don’t need names? Take a look here: “SAC13 week”.

Reference dates

SAC13 is anchored with the closest day to the March equinox in the Gregorian year 2000:

$$ \boxed{ \begin{array}{r:rlr} \text{SAC13} & 1^{\text{st}} &\negthickspace\negthickspace\text{March}\ & \negthickspace\negthickspace\negthickspace\negthickspace\negthickspace\text{M000}\newline \text{Greg.C.} & 20^{\text{th}} &\negthickspace\negthickspace\text{March}\ & \negthickspace\negthickspace\negthickspace\negthickspace\negthickspace\text{2000}\newline \text{JDN} & &\negthickspace\negthickspace{}2451624 & \end{array} } $$

Even though this date equality was originally used to develop the technical details of SAC13, like the leap year rule, it has actually low technical significance, because for the actual software implementations this equality is projected backward to a different starting point. It really could have been any other year, but I chose the Gregorian year 2000 as an example and original starting point, because it’s fairly recent so people can relate to it, and it’s a nice round number. If you are interested in different dates, check out the calculator.

Benefits

Here is a quick summary of some benefits of SAC13 compared to other proposals and the Gregorian Calendar. This is just a quick overview. Check out the FAQs and comparisons to other proposals if you want details, reasons, and explanations behind the SAC13 design decisions.

• Fixed layout. Every Month. Not only from year to year, or quarter to quarter, like other proposals.
• Stupidly simple layout, 7 × 4. Sometimes there is an additional day, because the solar system is messy.
• All weeks, months, years start with the same weekday (D1).
• Months and quarters are more comparable than in other calendars because, they have at most a single extra day.
• There are no negative years. This simplifies historical dates and correct software implementations.
• It doesn’t have “blank” days “outside” the calendar, like other 13 month proposals.
• The calendar layout, documentation and it’s reference implementation in various programming languages is in the public domain (CC0).

Downsides

Every calendar has downsides — even SAC13 😂. The only difference is that this proposal is also honest and transparent about that. Maybe even the only proposal that does that. Calendars have many conflicting requirements (or “nice to have“s) which directly contradict each other, so it’s always a trade-off about what’s most useful and important and which downsides are acceptable.

Finding a good calendar design is basically a process of choosing the downsides in a way that trying to fix any of them would create even bigger issues and a worse calendar for most people. Here are the downsides SAC13 intentionally chooses to accept as trade-offs:

• SAC13 will (once or twice a year) have a week with an additional day, to keep the calendar in sync with the solar system, and thus fall out of sync with the “Gregorian Week”. This is also called breaking the week cycle.
• Years of this calendar are not congruent with the Gregorian Calendar. SAC13’s New Year is roughly 2½ months after the Gregorian New Year.
• The leap year rule is more complicated than in the Gregorian Calendar.
• Quarters are not aligned with whole months, but only weeks.

Here are additional downsides that are not trade-offs, but are unavoidable consequences of switching to a new calendar system. All calendar proposals (incl. SAC13) share those:

• Switching to a new calendar (especially on a large scale, like globally) is unimaginably expensive and a huge effort.
• All dates will be different. Anniversaries, wedding dates and birthdays, Halloween 🎃, etc.

Deep dive?

Ready to go down the rabbit hole? These were just the basics about SAC13. If you’d like to know more about the reasons behind the decisions, technical explanations and what happens to all the birthdays you can check out our FAQs or comparisons to other proposals.