Weekday Calculator

Why the day of the week is arithmetic, not memory

The weekday of a date is fixed by the calendar rules, so it can be computed instead of remembered. Every date maps to one of seven days through a formula, and the formula only needs the day, the month and the year. That is what this page does, and it is also what your phone does when you scroll back to 1998.

The Gregorian calendar repeats every 400 years, which is 146,097 days, and that number divides by 7 exactly. So October 17, 2026 and October 17, 2426 fall on the same weekday. The repetition is the reason a formula can exist at all: without a fixed cycle, the weekday would be arbitrary data that had to be looked up.

Two rules do all the work. The first is the leap year rule, which adds a day every four years with exceptions. The second is the century anchor, which sets the starting weekday for each 100 year block. Get those two right and any date from 1583, when the Gregorian calendar took hold, to the far future can be solved on paper.

Zeller's congruence, step by step

Zeller's congruence is the classic formula, published in 1882 and still the shortest route from a date to a weekday. It reads:

h = (q + floor(13(m + 1) / 5) + K + floor(K / 4) + floor(J / 4) + 5J) mod 7

Here q is the day of the month, m is the month with January and February counted as months 13 and 14 of the previous year, K is the last two digits of the year, and J is the century. The result h runs from 0 to 6, where 0 is Saturday, 1 is Sunday, and so on to 6 for Friday.

Run it for October 17, 2026. The day is q = 17, the month is m = 10, K = 26 and J = 20. The month term is 13 x (10 + 1) = 143, and 143 / 5 = 28.6, which floors to 28. The year terms are 26 for K, 26 / 4 = 6.5 floored to 6, and 20 / 4 = 5. The century term is 5 x 20 = 100. Add them: 17 + 28 + 26 + 6 + 5 + 100 = 182. Then 182 / 7 = 26 with a remainder of 0, and 0 is Saturday.

The January and February shift is the step people forget. For January 2027 you would use m = 13 and year 2026, not m = 1 and 2027. Skip that and every January and February answer comes out one day off.

The doomsday method, which fits in your head

John Conway's doomsday rule trades the arithmetic for a short list of anchor dates. Every year has a doomsday, a weekday shared by a set of easy-to-remember dates. Once you know the year's doomsday, any other date is a matter of counting forward or back in sevens.

The anchors are chosen because they are easy to recall: 4/4, 6/6, 8/8, 10/10 and 12/12 all land on the doomsday, and so do 5/9, 9/5, 7/11 and 11/7. March 14 is doomsday, and so is pi day. In January it is the 3rd in a common year and the 4th in a leap year, and in February it is the last day of the month.

For 2026 the doomsday is Saturday, so October 10 is a Saturday and October 17 is a Saturday too, seven days later. That is the whole method: find the year's doomsday, find the nearest anchor, count in sevens. The formula and the rule agree, which is a good way to check either one.

Leap years, century years and the 400 rule

A year is a leap year if it divides by 4, unless it also divides by 100, in which case it is not, unless it divides by 400, in which case it is. The rule exists because a solar year is 365.2422 days, not 365.25, and the calendar has to shed the difference somewhere.

The century exception is where most people go wrong. 1900 divides by 4 and by 100 but not by 400, so it was not a leap year. 2000 divides by 400, so it was. 2100 will not be. A date calculator that ignores the rule gets February 29, 1900 as a real date, and every weekday after it shifts by a day.

The century also sets the starting weekday. The anchor for each 100 year block moves back two days per century, except across a 400 year boundary where it moves back one, which is the same exception wearing a different hat.

For a year inside the century, take the last two digits, divide by 12, keep the remainder, divide the remainder by 4, and add the quotient, the remainder and that second quotient to the anchor. For 2026: 26 / 12 = 2 with a remainder of 2, and 2 / 4 = 0.5, which floors to 0, so 2 + 2 + 0 = 4. Tuesday plus 4 days is Saturday.

Three dates that trip people up

The rules are easy to state and easy to misapply. These three dates catch most of the mistakes, and each one is worth checking against a calculator you trust.

January 1, 1900 was a Monday. The century year was not a leap year, which is why the 1900s start on a Monday rather than the Tuesday that a naive four year cycle would predict. Anyone who has debugged a spreadsheet date from that era has met this one.

January 1, 2000 was a Saturday. The year 2000 was a leap year because it divides by 400, and the century anchor for the 2000s is Tuesday. The combination lands on Saturday, which is why the widely repeated claim that the millennium started on a Monday is wrong by two days.

February 29, 2024 was a Thursday. A leap day takes the weekday of the day before it plus one, so February 28, 2024 was a Wednesday and March 1 was a Friday. The leap day is the only date that exists in one year out of four, and it is the reason a birthday on that date has a weekday that changes every time it appears.

Each of these can be confirmed with the U.S. Naval Observatory's published calendars, which are the reference used for official dates in the United States.

Time zones: why the same date can be two days

A calendar date is local. A moment in time is not. The two diverge whenever a timestamp crosses a time zone boundary, and the weekday can change even though nothing about the date did.

Take October 17, 2026 at 00:30 UTC. In Los Angeles, which is seven hours behind in October, that moment is still October 16, a Friday. In Tokyo, nine hours ahead, it is October 17 at 09:30, a Saturday. One timestamp, two dates, two weekdays, and neither is wrong.

The same thing happens on a red-eye flight. Leave Los Angeles on a Friday at 22:00 and land in New York at 06:00 the next morning: the departure date is Friday and the arrival date is Saturday, and the flight took five hours of clock time. Airlines print both dates for exactly this reason.

Programming has the same trap. A date stored as 2026-10-17T00:00:00Z is October 17 in London and October 16 in Denver, so a system that renders it in local time can show the wrong day to half its users. Store the date as a date, without a time, when the weekday is what matters. The NIST time and frequency division keeps the official US time scales that these conversions are checked against.

Week numbers, day of year and the 53-week year

Once you have the weekday, three more numbers come free. The day of the year for October 17, 2026 is 290, because the first nine months hold 273 days and 273 + 17 = 290. With 365 days in the year, that leaves 365 - 290 = 75 days, so the date sits three quarters of the way through.

The ISO week number is 42 for that date. ISO 8601 counts weeks from Monday, and week 1 is the week containing the first Thursday of the year, which is why a year can start in week 52 or 53 of the year before. January 1, 2026 was a Thursday, so week 1 began on December 29, 2025.

Weekday counts are the third number. A common year is 52 weeks plus one day, so the weekday of January 1 appears 53 times and every other weekday 52 times. In 2026, January 1 was a Thursday, so 2026 has 53 Thursdays. A leap year starting on the same weekday would have 53 of two weekdays instead.

That table is also a quick sanity check on the December calendar. December 31, 2026 falls on a Thursday, which is what the 53 Thursday count predicts, and it means the year ends on the same weekday it started.

Doing it in code without the usual bugs

JavaScript's Date object counts months from zero, so new Date(2026, 9, 17) is October 17, not September 17. That off-by-one is the most common weekday bug in web code, and it survives testing because the weekday is often close enough to look plausible.

The second bug is time zone. new Date('2026-10-17') is parsed as UTC midnight, but new Date(2026, 9, 17) is parsed as local midnight. In New York those two values are four hours apart, and in a zone far enough west the local date can land on the previous day. Use Date.UTC and the getUTCDay method when the input is a calendar date with no time attached.

The third bug is daylight saving. Adding 86,400,000 milliseconds to a timestamp is not the same as adding one calendar day across a spring-forward boundary, because that day is 23 hours long. Add days with setUTCDate and the arithmetic stays honest.

The calculator on this page avoids all three by parsing the date fields by hand and working in UTC throughout. It is a short function, and the version that ships is the version that passed a set of known dates including 1900, 2000 and a leap day.