Your Weekly Note for New Year's Day Is Filed Under the Wrong Year — 2026 Has a Week 53

A weekly note's filename needs the week's own year, not the calendar year. Written as %Y-W%V or YYYY-[W]WW, Friday 1 January 2027 becomes 2027-W53 — a week 2027 does not have. Written as %G-W%V or GGGG-[W]WW, it is 2026-W53, where it belongs. 2026 has 53 ISO weeks, so this changeover is the one to test.

The rule comes from ISO 8601, and Markus Kuhn of the University of Cambridge Computer Laboratory states its consequence in one line: "the week before week 01 of a year is the last week (52 or 53) of the previous year even if it contains days from the new year."¹ A week is one unit — and it carries one year.

Python's documentation gives that year its own code, %G — "the year that contains the greater part of the ISO week" — and then adds a warning that is easy to read past: "Also note that %G and %Y are not interchangeable."²

The damage is small and exact. In the 2026→2027 changeover, a calendar-year template misnames three notes: Friday 1, Saturday 2 and Sunday 3 January 2027. Monday to Thursday, 28–31 December, come out right under either format.

Three days is enough to file your weekly note for New Year's Day under the wrong year. They split one week across two files, and the stray file carries a week number its own year will never reach. The fix is one letter — and the time to make it is before Monday 28 December 2026, when week 53 begins.

The single habit: name the week with the week's own year

Pair an ISO week number with the ISO week-year, every time. In Python and GNU date that is %G-W%V; in moment.js tokens, which several note tools use for filenames, it is GGGG-[W]WW. The week-year equals the calendar year on almost every day of the year. It differs only on a few days at the turn of the year.

The ISO rule fits in two sentences. Weeks start on Monday, and Python's definition of %V fixes the first one: "ISO 8601 week as a decimal number with Monday as the first day of the week. Week 01 is the week containing Jan 4."² Everything else follows from that anchor.

The same documentation, describing date.isocalendar(), gives the arithmetic: "The ISO year consists of 52 or 53 full weeks, and where a week starts on a Monday and ends on a Sunday."³ Full weeks only. A week is never cut in half at New Year.

GNU's manual for date says it from the other side. Its %V entry reads: "If the week containing January 1 has four or more days in the new year, then it is considered week 1; otherwise, it is week 53 of the previous year, and the next week is week 1."⁴

Its %G is the matching year — the same as %Y, "except that if the ISO week number (see '%V') belongs to the previous or next year, that year is used instead."⁴

So the week owns its year. The calendar only owns the day.

That is why the pairing matters. %V answers "which week", %G answers "which week's year", and %Y answers a different question entirely — which year the day falls in. Put %Y in front of %V and the filename asks two questions of two different calendars.

Does 2026 have 53 weeks?

Yes. 2026 begins on a Thursday, so under ISO 8601 it has 53 weeks, not 52. Week 53 runs from Monday 28 December 2026 to Sunday 3 January 2027. The previous 53-week year was 2020 and the next is 2032, so a weekly template written since early 2021 has never met one.

The 53-week years between 2000 and 2040 are 2004, 2009, 2015, 2020, 2026, 2032 and 2037 — computed with Python 3.12's isocalendar() and checked against GNU coreutils date 9.4 on 9 October 2026. The pattern is the Thursday rule: a year gets a 53rd week when it starts on a Thursday, or when it is a leap year that starts on a Wednesday.

2027 starts on a Friday. It has 52 weeks.

That makes 2027-W53 a name for nothing — a file with no week to belong to. Python agrees: date.fromisocalendar(2027, 53, 1) raises ValueError: Invalid week: 53. The standard library refuses, outright, the filename a calendar-year template writes on New Year's Day 2027.

The previous changeover produced the same artifact. On Friday 1 January 2021, %Y-W%V printed 2021-W53 — a week 2021 also lacked.

Week 53 is not the only time the bug fires — the same format misnamed 29–31 December 2025 as well. A week 53 just makes it visible, because the stray filename points at a week that does not exist.

Three naming schemes, and the one your template uses

Weekly filenames come from three schemes. Calendar year plus ISO week (YYYY-[W]WW, %Y-W%V) breaks at year ends. ISO year plus ISO week (GGGG-[W]WW, %G-W%V) follows ISO 8601. Locale year plus locale week (gggg-[W]ww) is self-consistent, but under a US English locale it does not match ISO names.

The moment.js documentation names the tokens precisely: GGGG is the "ISO 4 digit week year", gggg the "Locale 4 digit week year", WW the "ISO week of year" and ww the "Locale week of year". It adds the rule that decides everything: "the lowercase tokens use the locale aware week start days, and the uppercase tokens use the ISO week date start days. Tokens are case-sensitive."⁵

The third row is not a bug. It is a different calendar. moment's docs give the US version: "in the United States, Sunday is the first day of the week. The week with January 1st in it is the first week of the year."⁶ Under that rule 2026 has no week 53 at all — Monday 28 December 2026 opens week 1 of 2027.

This scheme matters because it is a common default. Liam Cain's Periodic Notes, a popular community plugin for weekly notes in Obsidian, documents its weekly format as "Defaults to gggg-[W]ww."⁷ His Calendar plugin ships the same default in its source.⁸ Locale weeks are a defensible design choice — a reader's week follows the reader's country.

The catch is mixing. Under a US English locale, gggg-[W]ww and ISO's GGGG-[W]WW give different labels on 52 days of 2025 — every Sunday — and on all 365 days of 2027, by our own count with moment 2.31.0. A vault that holds ISO-named files, such as the 2026-W20.md names in our weekly review template, will disagree with a US-locale default for the whole of next year.

Users notice at the boundary. On 29 December 2020, one Calendar user wrote: "Yesterday I let the plug-in create a new note for this week, which is 1/2021. I want it to be 53/2020. Is there anything I can do?"⁹ Both answers were correct — in two different calendars. Which one a given reader sees depends on their language settings — so check the output, not the assumption.

Same four letters, opposite meanings

YYYY does not mean the same thing everywhere. In moment.js it is the calendar year — January to December, no exceptions. In libraries that follow the Unicode date-pattern standard, capital Y is the week-year: UTS #35 defines it as "Year in “Week of Year” based calendars in which the year transition occurs on a week boundary; may differ from calendar year ‘y’ near a year transition."¹⁰

date-fns 4.4.0 is blunt about the hazard. Its format notes say "YY and YYYY tokens represent week-numbering years but they are often confused with years," and by default a pattern like YYYY-MM-dd throws a RangeError instead of formatting.¹¹

A format string copied from one tool to another can flip its meaning without changing a character.

Where the format string lives in your tool

Check the tool that writes the filename, not the note app around it. Obsidian's core Daily notes plugin names files by calendar date, YYYY-MM-DD, and covers days only. Weekly names come from a community plugin's setting, a template you typed, or a script. Each has its own documented default, and its own token family.

Obsidian's help page for Daily notes states the daily default directly: "By default, Obsidian creates a new empty note named after today's date in the YYYY-MM-DD format."¹² A calendar date has no week-year problem — every part of it comes from the same calendar. That format has its own guide, how to name your note files, and our daily notes template uses it.

Templater's tp.date.now also defaults to YYYY-MM-DD and points to the moment.js reference for anything else, so a weekly name there is whatever tokens you type.¹³

Logseq's file-graph configuration, as of version 0.10.9, sets the journal filename default to yyyy_MM_dd — lowercase, so calendar year, in the Unicode style.¹⁴ It has no native weekly note — and its daily default is safe.

The risky spot is the one you wrote yourself.

YYYY-[W]WW is the natural thing to type into a template field — it looks like a year and a week. It is the first row of the scheme table.

The five-minute version: test four dates

Run four dates through your format string: Monday 29 December 2025, Monday 28 December 2026, Friday 1 January 2027 and Monday 4 January 2027. A correct ISO template prints 2026-W01, 2026-W53, 2026-W53 and 2027-W01. Any 2025-W01 or 2027-W53 in that output means the year token is wrong.

1. Find the format string. It lives in a template file, a plugin's settings panel, or a script — wherever the filename is built.
2. Read the year token. YYYY or %Y is the calendar year; GGGG or %G is the ISO week-year; gggg is the locale week-year.
3. Read the week token. WW or %V is the ISO week; ww is the locale week.
4. Check that they match. Year and week must come from the same scheme — both ISO or both locale.
5. Run the four dates. Use the commands below, or set your computer's date and create a note.
6. Compare with the table. Any cell that differs from your intended column is a misfile waiting for December.

The first two columns come from Python 3.12.3 and GNU coreutils date 9.4, which print identical strings. The locale column comes from moment.js 2.31.0 with its default English locale. All were run on 9 October 2026.

# Python 3.7 or later
python3 -c 'import datetime as d
for s in ["2025-12-29","2026-12-28","2027-01-01","2027-01-04"]:
    x=d.date.fromisoformat(s); print(s, x.strftime("%Y-W%V"), x.strftime("%G-W%V"))'

# GNU date (Linux)
for d in 2025-12-29 2026-12-28 2027-01-01 2027-01-04; do
  date -d "$d" '+%F  %Y-W%V  %G-W%V'
done

# moment.js tokens (Node.js, after: npm install moment)
node -e 'const m=require("moment");
for (const s of ["2025-12-29","2026-12-28","2027-01-01","2027-01-04"])
  console.log(s, m(s).format("YYYY-[W]WW"), m(s).format("GGGG-[W]WW"), m(s).format("gggg-[W]ww"))'

Swap your own format string into the last line if it differs. Four lines of output settle the question — before December does.

The thirty-minute version: fix the template, then the files

Change one token, then clean up after it. Swap the calendar year for the week-year in every place the format string lives — template, plugin setting, script. Then find the notes the old format already misnamed, merge each into the file its week owns, and update any links that point at the old name.

Fix every copy of the format string. YYYY-[W]WW becomes GGGG-[W]WW; %Y-W%V becomes %G-W%V. Search your notes folder for the old string — the same pattern often sits in a template's frontmatter, its title line and its filename rule.

Find last winter's stray note. The 2025→2026 changeover went wrong in the other direction. Monday to Wednesday, 29–31 December 2025, were named 2025-W01 — the same name as the week of 1 January 2025.

What happened next depends on the tool — it may have opened January's note, refused, or written over it. Open 2025-W01.md and look for late-December entries. They belong in 2026-W01.md.

Know which days to check in any year. By our count, %Y-W%V misnames at most three days a year, always at one end:

• 2024: 30–31 December · 2025: 29–31 December · 2026: none
• 2027: 1–3 January · 2028: 1–2 January · 2029: 31 December

Give folders the week-year too. A calendar-year folder above a week-year filename splits the same way. One Periodic Notes user, filing weekly notes under the format /YYYY/MM MMMM/YYYY-[W]ww, reported: "You should now have a properly named weekly note, but it has been saved in 2025/12 December/".¹⁵ A week has no single month — so file weekly notes by week-year alone.

Choose a scheme before 28 December. Switching from US-locale gggg-[W]ww to ISO names changes every label in 2027 — switch before the year starts, not in March. A "start week on Monday" setting does not make locale weeks ISO.

That setting moves the first day of the week but keeps the US first-week rule — the week containing 1 January. With Monday set, Monday 4 January 2027 is still 2027-W02 in US English, against ISO's 2027-W01, by our test with moment 2.31.0.

Update the links. A renamed file breaks every [[2027-W53]] that pointed at it. Rename through the app if it rewrites links, or search for the old name afterwards.

Common mistakes

Five token mistakes produce every misfile described here. Each pairs a year and a week from two different schemes, pairs a week-year with a calendar month and day, or assumes a setting does more than it does. Most of them pass a casual test in June and fail only at the turn of the year.

• A calendar year in front of an ISO week. %Y-W%V or YYYY-[W]WW. Friday 1 January 2027 becomes 2027-W53.
• A week-year in front of a month and day. %G-%m-%d turns Monday 29 December 2025 into 2026-12-29, a date a year away. GNU's manual says the format %G-%m-%d "is probably a mistake, since it combines the ISO week number year with the conventional month and day."⁴
• A locale week behind a calendar year. YYYY-[W]ww on Sunday 27 December 2026, in US English, prints 2026-W01 — the name of a file from January 2026.
• Treating "start week on Monday" as ISO. It changes the first day, not the first-week rule.
• Calendar folders above week names. YYYY/MM/ folders put the first week of a year into the previous December.

The second mistake is the famous one — and it runs in the opposite direction to the first.

On 29 December 2014 a Hacker News post titled "If you're using YYYY in your JVM service or %G in anything, fix it now" drew 228 points and 73 comments.¹⁶

Its author opened with: "The single character G instead of Y took down Twitter's API today."¹⁶ That cause was the diagnosis of developers on Hacker News — not Twitter's. Twitter's own statement said only that the outage "was due to a bug in our front end code", while The Register reported a bug that "led Twitter's servers to believe it was 2015."¹⁷

The weekly-note bug and the 2014 thread are the same confusion between two years, run in two directions. One puts the calendar year where the week-year belongs. The other puts the week-year where the calendar year belongs.

Careful engineers have tripped on the same two years

This is not a beginner's error. When a Python user asked in 2011 for a way to turn an ISO week back into a date, the example request paired a calendar-year token with an ISO week. The contributor who started on it hit the year mismatch within three weeks, and %G arrived in Python 3.6.

Erik Cederstrand opened the request on the CPython tracker on 5 May 2011: "it is not possible to do the reverse; calculate the date from a year, ISO week number and weekday."¹⁸ His example of the wanted behaviour was datetime.strptime('2011221', '%Y%V%u') — calendar year, ISO week, ISO weekday. It is the pairing this post warns against.

On 26 May 2011 the contributor aganders3 named the problem: "The problem comes when the ISO year does not match the Gregorian year for a given date. I think this should be fixed by implementing the %G directive (ISO year, which is present in strftime) as well."¹⁹ Python's documentation now records the result: "Added in version 3.6: %G, %u and %V were added."²

These were careful engineers, reading the standard closely. The two years still caught them — which is the point.

Formatting is an ordinary place for date code to fail. A 2025 study by Tiwari and colleagues at the MSR conference examined 151 date and time bugs in open-source Python software and found that "23.2% of bugs occur when formatting date/time information for printing or writing to a database."²⁰

One fix in that study came down to the first day of the week: "datetime treats Monday as the first day of the week whereas crontab treats Sunday as the first day of the week. The fix involves a single-line change to the computed index."²⁰

The study covers Python projects, not note files, and it does not measure week-years. It is context — not a count of misnamed weekly notes. The %G and GGGG tokens are not the villains either — paired with an ISO week, they are exactly right.

Frequently Asked Questions

These answers cover the questions people ask at the turn of each year, from "Does 2026 have 53 weeks?" to which letter goes in front of the week number. Every date below was computed with Python 3.12.3, GNU date 9.4 and moment.js 2.31.0 on 9 October 2026, and can be re-run with the commands above.

Does 2026 have 53 weeks?

Yes. 2026 begins on a Thursday, so its ISO calendar has 53 weeks. Week 53 runs from Monday 28 December 2026 to Sunday 3 January 2027. It is the first 53-week year since 2020; the next is 2032. Under a US English locale week, by contrast, 2026 has 52 weeks.

Why is my weekly note for January 1 named with the wrong year?

Your filename probably pairs the calendar year with an ISO week number, as in YYYY-[W]WW or %Y-W%V. On 1 January 2027 that prints 2027-W53, a week 2027 does not have. Use the ISO week-year instead: GGGG-[W]WW or %G-W%V, which prints 2026-W53.

What is the difference between YYYY and GGGG?

In moment.js, YYYY is the calendar year and GGGG is the ISO week-year — the year that owns the week. They agree on almost every day and differ only around New Year. In Unicode-style libraries such as date-fns, capital Y itself means week-year, so the same letters can mean the opposite.

What is the difference between %Y and %G?

%Y is the calendar year of the date. %G is the ISO 8601 year that contains the greater part of the ISO week, so it matches %V. Python's documentation states that the two "are not interchangeable". Use %G with %V for week names and %Y with month and day for dates.

Is week 1 the week with January 1 or January 4?

It depends on the scheme. ISO 8601 week 1 is the week containing 4 January, which is the same as the first week with a Thursday. moment.js documents the US locale rule differently: weeks start on Sunday, and the week containing 1 January is week 1. The two rules disagree in many years.

Does "start week on Monday" make my week numbers ISO?

No. Under a US English locale, changing the start day to Monday leaves the first-week rule unchanged — week 1 is still the week containing 1 January. In our test with moment.js 2.31.0, Monday 4 January 2027 stayed 2027-W02 with Monday set, where ISO says 2027-W01. Use ISO tokens for ISO names.

When is the next year with 53 weeks?

After 2026, the next 53-week ISO years are 2032 and 2037. Before it came 2004, 2009, 2015 and 2020. A year has 53 ISO weeks when it starts on a Thursday, or when it is a leap year starting on a Wednesday. Each one makes the following New Year a test of your template.

The week number was never the problem. The year in front of it was.

mnmnote.com keeps your notes as open Markdown on your own device — the name you give a week is yours to choose, and yours to correct.