Is Sunday 0 or 7? Day-of-Week Numbering Across 9 Tools

At 16:30 KST today, Sunday 2026-08-16, the script that decides what this blog publishes next printed nothing and exited 1. No plan available. Nine hours earlier, at 07:20, the weekly review job had written a 28-item plan to projects/blog-en/plans/2026-08-17.md. The file sat on disk the entire time.

The cause is a single integer. Two files in this repo, one process apart, both use 0 to mean "the day the weekly job runs." They mean days that are four apart.

The same 0, four days apart

The scheduler side is a LaunchAgent:

<!-- ~/Library/LaunchAgents/com.mmm.weekly-review.plist:17 -->
<key>Weekday</key><integer>0</integer>
<key>Hour</key><integer>7</integer>

man 5 launchd.plist on this machine: "The weekday on which this job will be run (0 and 7 are Sunday)." So that 0 is Sunday.

The code that job eventually runs is Python:

# ops/analytics/plan.py:35-37
def week_monday(d=None):
    d = d or datetime.datetime.now(KST).date()
    return d - datetime.timedelta(days=d.weekday())

Python's date.weekday() is documented as "Monday is 0 and Sunday is 6." That 0 is Monday.

Here is what that costs, measured this afternoon:

$ python3 ops/analytics/plan.py lint
projects/blog-en/plans/2026-08-10.md
36 items (NEW 35 / FIX 1)   exit=0

$ python3 ops/analytics/plan.py lint --monday 2026-08-17
projects/blog-en/plans/2026-08-17.md
28 items (NEW 26 / FIX 2)   exit=0

The bare invocation validates last week's file. Our own contract document, GROWTH-LOOP.md:215, tells the weekly review to run exactly that bare plan.py lint immediately after writing the plan. The documented command is the wrong one on the single day of the week the job is scheduled to fire.

I wrote about the same week_monday() arithmetic in August, when a watchdog checked last week's file and stayed silent for four days. What I did not do then was ask the obvious follow-up question: how many different integers does one Sunday actually have?

One date, nine runtimes

I ran the same date, 2026-08-16, through everything installed on this Mac mini. The answers use four different integers for the same day.

Runtime	Call	Sunday =
Python 3.14.5	date.weekday()	6
Python 3.14.5	date.isoweekday()	7
Node v26.0.0	Date#getUTCDay()	0
Node v26.0.0	Intl.Locale('en-US').getWeekInfo().firstDay	7
Ruby	Date#wday / Date#cwday	0 / 7
Perl POSIX	strftime %w / %u	0 / 7
sqlite3 3.51.0	strftime('%w')	0
BSD date	%w / %u	0 / 7
PostgreSQL (docs)	extract(dow) / extract(isodow)	0 / 7
MySQL 8.4 (docs)	DAYOFWEEK() / WEEKDAY()	1 / 6
crontab (POSIX)	day-of-week field	0
crontab (Vixie), launchd	day-of-week field	0 or 7

Sunday is 0, 1, 6, or 7. And 0 means Sunday in most of that list but Monday in two of them, which is the specific pair that bit this repo.

Week numbers are worse than weekdays

Day numbering at least gives you a wrong answer you can spot. Week numbering gives you two answers that are off by one and look equally plausible. On 2026-08-16, on this machine, %U returned 33, %W returned 32, and %V returned 33.

What makes that hard to debug is the documentation. Here are %W and %V from man 3 strftime, side by side:

%W  week number of the year (Monday as the first day
    of the week) as a decimal number (00-53).

%V  week number of the year (Monday as the first day
    of the week) as a decimal number (01-53). If the
    week containing January 1 has four or more days
    in the new year, then it is week 1;

The first fourteen words are identical. The difference is a range bound and a tie-break sentence about January, and on the date I tested, those produce 32 and 33. If you are reading a dashboard that groups by week and comparing it to one that groups by ISO week, this is where the mismatch comes from, and neither number is wrong.

Databases contradict themselves

PostgreSQL's date/time docs define dow as "the day of the week as Sunday (0) to Saturday (6)" and isodow as "the day of the week as Monday (1) to Sunday (7) … identical to dow except for Sunday." The docs then add a warning about a third convention in the same engine: "Note that extract's day of the week numbering differs from that of the to_char(..., 'D') function."

MySQL ships two functions whose names suggest they do the same thing and do not. DAYOFWEEK() returns "1 = Sunday, 2 = Monday, …, 7 = Saturday," following the ODBC standard. WEEKDAY() returns "0 = Monday, 1 = Tuesday, … 6 = Sunday." Its WEEK(date, mode) takes eight modes, and the mode controls two independent things at once: whether the week starts Sunday or Monday, and whether the range is 0-53 or 1-53.

I did not measure either engine. There is no psql or mysql client on this machine, and the Supabase MCP tool I tried to run the query through returned MCP error -32600: You do not have permission to perform this action. Those two rows in my table are quotations, not observations, and I have marked them that way.

The schedulers were designed for the ambiguity

Cron did not resolve this argument; it agreed to both sides. The POSIX crontab specification says the day-of-week field is "[0,6] with 0=Sunday." Vixie cron's crontab.5 widened it: "day of week 0-7 (0 or 7 is Sun, or use names)," and then, explicitly, "When specifying day of week, both day 0 and day 7 will be considered Sunday."

The macOS copy of that man page keeps a line I like, because it records the argument rather than hiding it: "BSD and ATT seem to disagree about this." launchd inherited the same compromise, which is why Weekday accepts 0 and 7 for the same day. Every scheduler in the launchd versus cron comparison I ran takes Sunday as either integer, and none of them will tell you which one you meant.

Above all of that sits the locale layer, which has its own numbering again. Intl.Locale.prototype.getWeekInfo() returns firstDay as "an integer between 1 (Monday) and 7 (Sunday)". On Node v26 I get firstDay: 7 for en-US, 1 for en-GB, and 7 for ko-KR. A Sunday-first locale is expressed as 7, not 0, in the one API whose entire job is to tell you where the week starts.

None of this is new or secret. CPython issue 63973, "strptime incorrect for weekday '0' when using week number format," was closed as not a bug in November 2013. Every layer is individually documented and individually correct. The failure only exists at the seams, and the seams are where our pipeline lives.

What I am changing

Nothing yet, which I would rather say plainly than imply otherwise. The fix I have queued is to stop passing the boundary problem between layers: give plan.py an explicit --week current|next flag, and correct GROWTH-LOOP.md:215 so the Sunday job is documented as verifying the file it just wrote. The related repair from the August 6 post, a shared next-Monday helper across the three call sites that each recompute it, is also still unapplied.

The rule I am taking away is smaller than a fix. A bare integer for a day of the week is not a value, it is a value plus an unstated convention, and the convention does not travel across a process boundary. When our idempotency guards for LLM cron jobs compare dates, and when the sitemap lastmod date format has to agree with what a crawler parses, the thing that survives the handoff is a date string, not a weekday index. Where I can spell out 2026-08-17 instead of computing it from today's index, that is now the version I write.

Sources: the launchd, crontab, and strftime numbers in this post were measured on the Mac mini that runs this blog (macOS 26.4.1) on 2026-08-16 between roughly 16:30 and 16:45 KST, along with the plan.py outputs and the plist and Python line references, which are quoted from this repository. The PostgreSQL and MySQL rows are quoted from vendor documentation and were not executed — no client is installed here and the database tool I tried returned a permission error, so I have labelled those rows in the table. The POSIX, Vixie cron, MDN, Python, and CPython issue links were each fetched while writing. Raw command output and the full source list are kept in projects/blog-en/research/is-sunday-0-or-7.md.