Weekly meal plan fails to populate specific week (Feb 9–16 2026)

[jacobsscoots]

Body

Summary

My Meal Planning page fails to generate/populate meals for the date range 9 Feb 2026 → 16 Feb 2026. Other weeks generate normally.

This looks like a date boundary / week calculation issue (or an edge case with how the range is built).

Expected

• The planner should generate meals for every day in the selected range (9–16 Feb 2026).
• Daily totals should hit macros within 1g for Protein/Carbs/Fat.
• Calories can be off by up to +50 kcal (but macros must be within 1g).

Actual

• The week 9–16 Feb 2026 fails to populate (UI shows missing/blank meals for those dates or generation fails).
• No daily entries get written for that date range (or they show as empty).

Reproduction steps

1. Go to Meal Planning
2. Select week/date range: 2026-02-09 to 2026-02-16
3. Click Generate (or whatever triggers meal generation / auto-portioning)
4. Observe the output for each day

Notes / Context

• The app supports two modes:
  1. Auto portioning: user sets daily calorie + macro targets and the system chooses grams per product
  2. Manual grams: user enters grams themselves
• This bug is in the auto mode (and may impact manual display too if both share the same date-range logic).

What I think is happening

Likely one of these:

• Week start logic mismatch (Sunday vs Monday weeks)
• Date parsing/timezone issue (dates shifting, end date excluded)
• Range loop using < endDate instead of <= endDate
• ISO week calculation bug (week/year boundary logic)
• Data keying uses formatted strings that don’t match (e.g. YYYY-MM-DD vs locale)

What I need help with

1. Identify the root cause for why that specific week fails
2. Patch the date-range/week logic so all dates populate reliably
3. Add a regression test that confirms:
   • Each day in 2026-02-09 → 2026-02-16 has meals generated
   • Daily macro totals are within 1g
   • Calories allowed variance: +50 kcal

Helpful info to include (I can provide)

• Screenshot of the week showing blanks
• Console error logs (if any)
• The files/functions responsible (date-range builder + generator)
• Sample product set + m

Tech details

• Framework: [e.g. Next.js/React]
• Date library: [date-fns/dayjs/moment/custom]
• Storage: [Supabase/Firebase/local storage/DB]
• Relevant functions/files:
  • ... (date range / week calc)
  • ... (meal generation / auto-portioning)

The GitHub file can be found here: https://github.com/jacobsscoots/lfinance

Guidelines

• I have read and understood this category's guidelines before making this post.

[SaTyle]

This issue is most likely caused by a date-range calculation bug, where the end date is excluded or shifted due to timezone or week-start logic.

✅ Most common cause
Many apps loop through dates using < endDate instead of <= endDate, which skips the final day and can break generation for certain weeks.

✅ What to check and fix

1. Fix the date loop
Make sure your range includes the end date:

let current = new Date(startDate);

while (current <= endDate) {
  generateMeals(current);
  current.setDate(current.getDate() + 1);
}

2. Normalize timezone
Convert all dates to the same timezone before processing:

const start = new Date(startDate + "T00:00:00");
const end = new Date(endDate + "T23:59:59");

3. Verify week-start logic
Ensure your app consistently uses either Monday or Sunday as the start of the week. Mixed ISO/local week logic can break specific ranges.

4. Avoid string-based keys
Store dates in YYYY-MM-DD format to prevent locale mismatches.

✅ Add a regression test

• Confirm meals generate for every day between 2026-02-09 and 2026-02-16.
• Validate macros within 1g and calories within +50 kcal.

Fixing the inclusive date range and normalizing timezone usually resolves this type of issue.

[jacobsscoots]

Thanks again for the detailed breakdown — it really helped.

I’m still pretty new to coding, which is why I’m using an AI builder (Lovable) to make the edits. I pasted your reply into ChatGPT to turn it into a clear plan, then ran that through Lovable. Lovable reported this fix:

Root cause (per Lovable): Monday was being treated as the end of the previous week in getShoppingWeekRange(), so Feb 9 (Mon) jumped back to Feb 1 instead of Feb 8

Fix: Updated Monday handling in src/lib/mealPlannerWeek.ts to go back 1 day (to Sunday) instead of 8 days

Tests added: src/lib/mealPlannerWeek.test.ts (3 regression tests for Feb 9–16 handling)

Verified: tests passing + UI shows Feb 8–16 populated, prev/next navigation works

But I’m still hitting a problem: when I click Generate meal, it still doesn’t load the correct “usage/output”, and it’s also throwing an error — even though the exact same setup works fine in MyFitnessPal (so the foods/macros themselves are valid).

I’ve uploaded a screen recording on GitHub showing the error and the behaviour. If you’re able to take a look and point me to what to check next (date key mismatch, timezone normalization, different range logic in the generator vs the week view, etc.) that would be massively appreciated.

chrome_ffwFA5Rawi.mp4

[jacobsscoots]

Just to let you know the end result I’m aiming for (once fixed):

1. When I select 9–16 Feb 2026 and click Generate, it should populate every day in that range with meals (no blanks).
2. Each day should show the correct food “usage” amounts (grams/quantities) and update totals properly.
3. Daily totals should match macros within 1g for Protein/Carbs/Fat (calories can be up to +50 kcal).
4. No errors thrown during generation, and week navigation stays correct.

[healer0805]

This pattern usually boils down to two bits of date logic drifting apart:

1. the week/range builder thinks 2026-02-09 belongs to the previous week, so it spits out a range that doesn’t match what the UI is asking for, and
2. the generator/write layer keys days differently than the UI reads them (ISO week vs locale week, UTC vs local midnight, YYYY-MM-DD vs toDateString()), so writes “succeed” but land under the wrong keys. ([GitHub]1)

Root cause to look for

• A “Monday special-case” like:

  • “if Monday, jump back 7/8 days”
  • or “treat Monday as end-of-previous-week”
    This will make Feb 9, 2026 (Mon) fall into a prior range and your 9→16 request ends up misaligned. ([GitHub]1)

Patch so it doesn’t trip you up again

Pick one rule and stick to it everywhere:

• Weeks start Monday (ISO-ish)
• Days are keyed as YYYY-MM-DD in a single timezone (local or UTC, but one)

Then:

• Build ranges inclusive (<= end)
• Normalize dates to start of day before formatting keys
• Make the planner UI and generator both consume the same getDaysInRange() helper

Example shape (date-fns style, but same idea in dayjs/moment):

export function dayKey(d: Date) {
  const x = new Date(d);
  x.setHours(0, 0, 0, 0);
  return x.toISOString().slice(0, 10); // YYYY-MM-DD (UTC key)
}

export function getDaysInRange(start: Date, end: Date) {
  const days: Date[] = [];
  const cur = new Date(start);
  cur.setHours(0, 0, 0, 0);

  const last = new Date(end);
  last.setHours(0, 0, 0, 0);

  while (cur <= last) {
    days.push(new Date(cur));
    cur.setDate(cur.getDate() + 1);
  }
  return days;
}

If you don’t want UTC keys, don’t use toISOString()—format in local time consistently instead. The key point is: don’t mix.

Why only 9–16 Feb 2026 blows up

That range is a perfect “boundary bait”:

• starts on a Monday
• spans 8 days (week + 1)
  So any code that assumes “a week is 7 days starting Sunday” or “endDate is exclusive” can fall through a crack.

Regression test that actually pins it down

Test the thing that matters: every key exists for that range.

• Range: 2026-02-09 → 2026-02-16
• Expect: 8 day keys generated
• Expect: generator writes 8 entries
• Expect: macros within 1g; calories ≤ target + 50

If your generator is deterministic (or can be seeded), assert totals; otherwise assert “not empty” + “within tolerance”.

Next place to dig when “Generate” still errors

If the week view is fixed but “Generate” throws:

• The generator is likely using a different range function (or different key formatter) than the week UI.

• Search for a second copy of:

  • getWeekRange, getShoppingWeekRange, startOfWeek, endOfWeek, toISOString, format(...), new Date(string)

Make them all call the same helper, then the bug can’t creep back in.

If you paste the two functions that (a) build the range and (b) write/read by date key, I can point out the exact mismatch that’s tripping it up.