I Made 6 Local LLMs Write a Holiday-Aware Calendar Script — This Time With US Holidays, and One Finally Got Everything Right

Last week I ran an experiment that ended in a massacre: I asked six local Qwen models (running on a single RTX 3090) to write a Google Apps Script that generates a yearly calendar with Japanese holidays highlighted and named. All six failed. The only script that ran without errors printed holidays from a law that was repealed ~30 years ago. (Japanese write-up here.)

A natural follow-up question: was the task hard, or was Japan hard?

So I reran the exact same experiment with one change — the prompt is in English and asks for US federal holidays. Same machine (RTX 3090, 24GB VRAM), same Ollama 0.32.6, same settings (8192 context, temperature 0.3, thinking off), one generation per model, no retries. Every promising script got executed in a real Apps Script project, driven by browser automation, and I verified the output spreadsheets by hand.

The answer: Japan was hard.

Scoreboard: Japan round vs. US round

Japanese holidays US federal holidays
Ran without errors 1 / 6 3 / 6
Correct holiday dates 0 / 6 1 / 6 fully correct (+2 mostly correct)

US round, model by model

Model Gen time Verdict
qwen3.6:27b 68.5s Fully correct. Ran clean, every 2026 federal holiday on the right date, readable layout
qwen3-coder:30b 32.2s Runs clean, but every floating holiday lands on a Sunday (off by one day); no Juneteenth
qwen3:32b 45.0s Runs; correct dates but holiday names hidden in cell notes, no Juneteenth, and it creates 13 sheets
qwen3.6:35b 48.8s Hardcoded 2026 dates — all correct! — then dies instantly on a setValues dimension mismatch
qwen3:14b 27.9s Thinks Valentine's Day is a federal holiday; layout drifts one day per row
qwen3:8b 87.5s Repetition collapse: 8,743 tokens declaring every single day of January "New Year's Day"

The winner: qwen3.6:27b

In the Japanese round, 27b had the smartest design and died on a hallucinated API call. In the US round it delivered the complete package: correct getNthWeekday helpers (3rd Monday of January is actually computed as the 3rd Monday), Juneteenth included, MLK Day on Jan 19, Presidents' Day on Feb 16, Thanksgiving on Nov 26 — all verified in the generated sheet.

qwen3.6:27b's calendar — fully correct

This is the first fully correct output across both experiments: 12 attempts (6 models × 2 countries), 1 perfect score.

The instructive failure: qwen3-coder:30b

The coding-specialist model produced the cleanest-running code again — and a wonderfully systematic bug. Its floating-holiday formula anchors the calculation to the weekday of January 1st instead of the target date, so MLK Day, Presidents' Day, Memorial Day, Labor Day, and Columbus Day all land exactly one day early — on Sundays:

qwen3-coder:30b — every floating holiday is a Sunday

A calendar where every federal holiday falls on a Sunday is the kind of output that looks fine at a glance and quietly poisons whatever consumes it. (It also skipped Juneteenth, a 2021 addition — training-data vintage strikes again.)

The overachiever: qwen3.6:35b

The strangest result. In the Japanese round, 35b annotated its own holiday data with "(wrong)" and shipped it anyway. In the US round it hardcoded every 2026 federal holiday correctly from memory — MLK Jan 19, Memorial May 25, Thanksgiving Nov 26, Juneteenth included. Then it crashed on the very first cell write, because it wrapped an array inside a 1×1 setValues call. Right data, dead code — the exact mirror image of coder:30b.

What the "correct" solution looks like

Same as the Japanese version: don't hardcode holidays, ask Google. Apps Script can read Google's US Holidays calendar directly:

const HOLIDAY_CALENDAR_ID = 'en.usa#[email protected]';

function fetchHolidays(year) {
  let cal = CalendarApp.getCalendarById(HOLIDAY_CALENDAR_ID);
  if (!cal) cal = CalendarApp.subscribeToCalendar(HOLIDAY_CALENDAR_ID); // see note below
  const events = cal.getEvents(new Date(year, 0, 1), new Date(year + 1, 0, 1));
  // filter observances (Valentine's Day etc.) against the federal holiday list...
}

Two pitfalls I hit while verifying, which explain why no model found this route:

  1. On a non-US Google account, getCalendarById returns null for the US holiday calendar — you have to subscribeToCalendar first. (Interestingly, the reverse route for Japan's "official holidays only" calendar is blocked entirely: subscribing throws "Action not allowed.")
  2. Google's holiday calendars mix observances (Valentine's Day, Halloween...) with actual federal holidays, and the event description field that should distinguish them is empty. You still need a name whitelist on top.

The reference implementation with those fixes generates the 11 federal holidays of 2026, named and colored, in one run:

Reference implementation

The takeaway: your local LLM is only as good as its training-data neighborhood

Same models, same task, same prompt structure. Change the country and the results flip:

  • US civic knowledge is abundantly represented in training data. Three models could recite or compute federal holidays; one got everything right. Nth-weekday rules ("4th Thursday of November") are well-trodden textbook problems in English.
  • Japanese civic knowledge is sparse and full of stale revisions. Holiday laws changed in 2000, 2003, 2016, 2020 — and the models serve a random vintage of that history with full confidence.

If you're deploying local LLMs for coding in a non-English locale, the failure mode is not "the code doesn't run." It's this: the code runs, the output looks plausible, and the domain facts inside it are quietly wrong. The only defense is executing the code and checking the output against ground truth — which is exactly the step I automated here (Puppeteer driving the Apps Script editor; the same pipeline from the Japanese article):

The verification pipeline in action

Total cloud API cost for both experiments: $0. Everything ran on one RTX 3090 next to my desk.