BUG: Shared trip page day calculation ignores timezone (s/[shareSlug]) #3

New issue

Closed

opened 2026-05-09 00:26:29 +00:00 by Mark · 1 comment

Mark commented

2026-05-09 00:26:29 +00:00

Owner

Description

In src/app/s/[shareSlug]/page.tsx, the inline getDayPlans() function (line 71-82) uses toISOString().split("T")[0] to group items by day, which ignores the trip timezone. This can cause items to appear on the wrong day for non-UTC timezones.

Code

const getDayPlans = (): DayPlan[] => {
  if (!trip) return [];
  const start = new Date(trip.startDate);
  const end = new Date(trip.endDate);
  const days: DayPlan[] = [];
  for (let d = new Date(start); d <= end; d.setDate(d.getDate() + 1)) {
    const dateStr = d.toISOString().split("T")[0];  // BUG: no timezone
    const dayItems = items.filter(item => item.startAt && new Date(item.startAt).toISOString().split("T")[0] === dateStr);  // BUG: no timezone
    days.push({ date: dateStr, dayNumber: days.length + 1, items: dayItems });
  }
  return days;
};

Impact

A trip with timezone "Asia/Tokyo" might show items on the wrong day
The private trip detail page (/trips/[tripId]) uses the correct buildDayPlans() from the domain module which handles timezone with toLocaleDateString(en-CA, { timeZone: timezone })
The shared view should use the same domain function for consistency

Fix

Use buildDayPlans() from @/domain/day-plan instead of the inline implementation, passing trip.timezone.

Alternatively, use toLocaleDateString(en-CA, { timeZone: trip.timezone }) for date string computation.

## Description In `src/app/s/[shareSlug]/page.tsx`, the inline `getDayPlans()` function (line 71-82) uses `toISOString().split("T")[0]` to group items by day, which ignores the trip timezone. This can cause items to appear on the wrong day for non-UTC timezones. ## Code ```typescript const getDayPlans = (): DayPlan[] => { if (!trip) return []; const start = new Date(trip.startDate); const end = new Date(trip.endDate); const days: DayPlan[] = []; for (let d = new Date(start); d <= end; d.setDate(d.getDate() + 1)) { const dateStr = d.toISOString().split("T")[0]; // BUG: no timezone const dayItems = items.filter(item => item.startAt && new Date(item.startAt).toISOString().split("T")[0] === dateStr); // BUG: no timezone days.push({ date: dateStr, dayNumber: days.length + 1, items: dayItems }); } return days; }; ``` ## Impact - A trip with timezone "Asia/Tokyo" might show items on the wrong day - The private trip detail page (`/trips/[tripId]`) uses the correct `buildDayPlans()` from the domain module which handles timezone with `toLocaleDateString(en-CA, { timeZone: timezone })` - The shared view should use the same domain function for consistency ## Fix Use `buildDayPlans()` from `@/domain/day-plan` instead of the inline implementation, passing `trip.timezone`. Alternatively, use `toLocaleDateString(en-CA, { timeZone: trip.timezone })` for date string computation.

Mark added the

security/medium

label

2026-07-27 19:19:31 +00:00

Mark referenced this issue from a commit

2026-08-12 03:46:36 +00:00

fix(api): validate lat/lng and item type, owner-only member/share authz, timezone-aware shared day plans, sanitize share secrets

Mark commented

2026-08-12 03:47:10 +00:00

Author

Owner

Fixed in commit a5510ba: the shared trip page (/s/[shareSlug]) hand-rolled day bucketing with toISOString() (UTC), ignoring trip.timezone — items near midnight landed on the wrong day. Now uses the domain buildDayPlans(items, start, end, timezone) helper, same as the member trip page.

Fixed in commit a5510ba: the shared trip page (/s/[shareSlug]) hand-rolled day bucketing with toISOString() (UTC), ignoring trip.timezone — items near midnight landed on the wrong day. Now uses the domain buildDayPlans(items, start, end, timezone) helper, same as the member trip page.

Mark closed this issue

2026-08-12 03:47:10 +00:00

Mark referenced this issue

2026-09-14 15:55:02 +00:00

[Security] HIGH: 5 critical/high dependency vulns #11