Problem
In app/api/wrapped/route.ts, the default year (when customYear is not provided) is calculated using the server's local timezone:
const year = customYear || new Date().getFullYear().toString();
However, the route already accepts and uses a tz parameter for fetching timezone-aware wrapped stats:
const wrappedStats = tz
? await getWrappedData(user, year, { bypassCache: shouldBypassCache }, tz)
: await getWrappedData(user, year, { bypassCache: shouldBypassCache });
This creates an inconsistency: a user near a year boundary (e.g. New Year's Eve/Day) in a different timezone than the server could get the wrong default year. For example, if the server is on UTC and a user is in UTC+13 (New Zealand), the server might still report the previous year while the user has already entered the new year locally — or vice versa.
This mirrors a pattern already correctly handled elsewhere in the codebase, e.g. app/api/streak/route.ts:
new Intl.DateTimeFormat('en-CA', { timeZone: timezone, year: 'numeric' }).format(new Date())
Root cause
The year calculation in wrapped/route.ts was written using plain new Date().getFullYear() without considering the tz parameter that the route already supports for other purposes.
Proposed fix
Use the tz parameter (when provided) to compute the default year, consistent with the timezone-aware pattern in streak/route.ts:
const year = customYear || (tz
? new Intl.DateTimeFormat('en-CA', { timeZone: tz, year: 'numeric' }).format(new Date())
: new Date().getFullYear().toString());
Problem
In app/api/wrapped/route.ts, the default year (when customYear is not provided) is calculated using the server's local timezone:
const year = customYear || new Date().getFullYear().toString();
However, the route already accepts and uses a
tzparameter for fetching timezone-aware wrapped stats:const wrappedStats = tz
? await getWrappedData(user, year, { bypassCache: shouldBypassCache }, tz)
: await getWrappedData(user, year, { bypassCache: shouldBypassCache });
This creates an inconsistency: a user near a year boundary (e.g. New Year's Eve/Day) in a different timezone than the server could get the wrong default year. For example, if the server is on UTC and a user is in UTC+13 (New Zealand), the server might still report the previous year while the user has already entered the new year locally — or vice versa.
This mirrors a pattern already correctly handled elsewhere in the codebase, e.g. app/api/streak/route.ts:
new Intl.DateTimeFormat('en-CA', { timeZone: timezone, year: 'numeric' }).format(new Date())
Root cause
The year calculation in wrapped/route.ts was written using plain new Date().getFullYear() without considering the tz parameter that the route already supports for other purposes.
Proposed fix
Use the tz parameter (when provided) to compute the default year, consistent with the timezone-aware pattern in streak/route.ts:
const year = customYear || (tz
? new Intl.DateTimeFormat('en-CA', { timeZone: tz, year: 'numeric' }).format(new Date())
: new Date().getFullYear().toString());