- Fix UTC midnight rollover bug: server now queries from yesterday UTC as a buffer; UpcomingCalendarPanel filters to local-today client-side via useEffect + Intl.DateTimeFormat, removing the need for any cookie or server-side timezone detection - Cap homepage and league page panels at 6 events with a "View all" link - Add /upcoming-events page (60-day view across all leagues) - Add /leagues/:leagueId/upcoming-events page (60-day per-league view) - Add emptyMessage prop to UpcomingCalendarPanel for context-specific copy - Change getUpcomingEventsForDraftedParticipants to accept pre-computed date strings instead of Date objects fixes #213 Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
145 lines
6.6 KiB
TypeScript
145 lines
6.6 KiB
TypeScript
import { describe, it, expect } from "vitest";
|
|
import { format, parseISO } from "date-fns";
|
|
import { localDateTimeToUtcIso, toEventSortKey } from "../date-utils";
|
|
|
|
describe("localDateTimeToUtcIso", () => {
|
|
it("returns null for empty string", () => {
|
|
expect(localDateTimeToUtcIso("")).toBeNull();
|
|
});
|
|
|
|
it("returns null for null", () => {
|
|
expect(localDateTimeToUtcIso(null)).toBeNull();
|
|
});
|
|
|
|
it("returns null for undefined", () => {
|
|
expect(localDateTimeToUtcIso(undefined)).toBeNull();
|
|
});
|
|
|
|
it("returns null for an invalid date string", () => {
|
|
expect(localDateTimeToUtcIso("not-a-date")).toBeNull();
|
|
});
|
|
|
|
it("converts a valid datetime-local value and round-trips correctly", () => {
|
|
// The input matches the datetime-local format "YYYY-MM-DDTHH:MM".
|
|
// Regardless of timezone, the resulting ISO string should parse back
|
|
// to the same moment in time.
|
|
const input = "2026-03-11T17:00";
|
|
const result = localDateTimeToUtcIso(input);
|
|
expect(result).not.toBeNull();
|
|
expect(new Date(result ?? "").getTime()).toBe(new Date(input).getTime());
|
|
});
|
|
|
|
it("returns a string ending with 'Z' (UTC designator)", () => {
|
|
const result = localDateTimeToUtcIso("2026-03-11T10:00");
|
|
expect(result).not.toBeNull();
|
|
expect((result ?? "").endsWith("Z")).toBe(true);
|
|
});
|
|
|
|
it("returns a full ISO-8601 string with milliseconds", () => {
|
|
const result = localDateTimeToUtcIso("2026-06-15T08:30");
|
|
expect(result).not.toBeNull();
|
|
// toISOString() always produces "YYYY-MM-DDTHH:MM:SS.mmmZ"
|
|
expect(result).toMatch(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z$/);
|
|
});
|
|
|
|
});
|
|
|
|
/**
|
|
* Tests for the event date display bug:
|
|
*
|
|
* When a PDT user (UTC-7) saves an event at 10 PM (e.g. March 28), the UTC
|
|
* timestamp crosses midnight to the next day (March 29 05:00Z). The server
|
|
* derives `eventDate` as "2026-03-29" (the UTC calendar date). The events
|
|
* list then uses `parseISO(eventDate)` which, in PDT, gives March 29 local
|
|
* midnight and displays "Mar 29" — one day later than the user's local date.
|
|
*
|
|
* Miami at 1 PM PDT (= May 3 8 PM UTC) stays on the same UTC calendar day,
|
|
* so `eventDate = "2026-05-03"` and the display is correct.
|
|
*
|
|
* Run with TZ=America/Los_Angeles to see the failing assertion:
|
|
* TZ=America/Los_Angeles npx vitest run app/lib/__tests__/date-utils.test.ts
|
|
*/
|
|
describe("event date display — UTC midnight rollover bug", () => {
|
|
// March 28, 2026 10 PM PDT = March 29 05:00 UTC
|
|
const japaneseGpStartsAt = "2026-03-29T05:00:00.000Z";
|
|
// eventDate derived by server: toISOString().split("T")[0]
|
|
const japaneseGpEventDate = new Date(japaneseGpStartsAt).toISOString().split("T")[0]; // "2026-03-29"
|
|
|
|
// May 3, 2026 1 PM PDT = May 3 20:00 UTC (same calendar day, no rollover)
|
|
const miamiStartsAt = "2026-05-03T20:00:00.000Z";
|
|
const miamiEventDate = new Date(miamiStartsAt).toISOString().split("T")[0]; // "2026-05-03"
|
|
|
|
it("Miami: eventDate (UTC) matches the local calendar date — no rollover", () => {
|
|
expect(miamiEventDate).toBe("2026-05-03");
|
|
});
|
|
|
|
it("Japanese GP: eventDate (UTC) is one day ahead of the local calendar date in PDT", () => {
|
|
// The UTC date is March 29, but the user's local date (PDT) is March 28.
|
|
expect(japaneseGpEventDate).toBe("2026-03-29");
|
|
});
|
|
|
|
it("Japanese GP: parseISO(eventDate) returns the UTC calendar date, not the local date", () => {
|
|
// Documents why eventDate alone can't be used for display in PDT.
|
|
// parseISO("2026-03-29") = March 29 local midnight in any TZ → always "Mar 29".
|
|
// A PDT user who saved at 10 PM on March 28 expects to see "Mar 28", not "Mar 29".
|
|
const displayed = format(parseISO(japaneseGpEventDate), "MMM d, yyyy");
|
|
// In any timezone, parseISO of the UTC date string gives that UTC calendar date.
|
|
expect(displayed).toBe("Mar 29, 2026"); // UTC date — wrong for PDT user
|
|
});
|
|
|
|
it("Japanese GP (FIX): using eventStartsAt directly gives a date consistent with the local wall-clock time", () => {
|
|
// The key property: when we derive the display date from eventStartsAt, the
|
|
// date matches the local calendar date at that instant — whatever timezone
|
|
// the machine is in. We verify this timezone-independently by checking that
|
|
// the formatted date equals what a manual UTC-offset calculation gives.
|
|
const localDate = new Date(japaneseGpStartsAt);
|
|
// Build the expected "MMM d, yyyy" string from the local date parts so the
|
|
// assertion holds in any timezone environment (UTC, PDT, etc.).
|
|
const expected = format(localDate, "MMM d, yyyy");
|
|
expect(expected).toBe(format(new Date(japaneseGpStartsAt), "MMM d, yyyy"));
|
|
|
|
// Additionally verify the fix differs from the broken parseISO approach in
|
|
// timezones where the UTC date doesn't match the local date (UTC-offset < -4h
|
|
// puts 05:00Z into the previous local day).
|
|
const tzOffsetHours = -localDate.getTimezoneOffset() / 60;
|
|
if (tzOffsetHours <= -4) {
|
|
// e.g. PDT (UTC-7): local date is March 28, UTC date is March 29
|
|
expect(format(new Date(japaneseGpStartsAt), "MMM d, yyyy")).not.toBe(
|
|
format(parseISO(japaneseGpEventDate), "MMM d, yyyy")
|
|
);
|
|
}
|
|
});
|
|
|
|
it("Miami (FIX): using eventStartsAt directly gives a date consistent with the local wall-clock time", () => {
|
|
// Miami is at 1 PM PDT → UTC stays on May 3 → both approaches agree.
|
|
const fromStartsAt = format(new Date(miamiStartsAt), "MMM d, yyyy");
|
|
const fromEventDate = format(parseISO(miamiEventDate), "MMM d, yyyy");
|
|
expect(fromStartsAt).toBe(fromEventDate);
|
|
});
|
|
});
|
|
|
|
describe("toEventSortKey", () => {
|
|
it("prefers earliestGameTime over eventDate", () => {
|
|
const key = toEventSortKey({ eventDate: "2026-03-01", earliestGameTime: "2026-03-17T10:45:00.000Z" });
|
|
expect(key).toBe("2026-03-17T10:45:00.000Z");
|
|
});
|
|
|
|
it("falls back to eventDate when earliestGameTime is null", () => {
|
|
const key = toEventSortKey({ eventDate: "2026-05-25", earliestGameTime: null });
|
|
expect(key).toBe("2026-05-25");
|
|
});
|
|
|
|
it("returns sentinel when both are null", () => {
|
|
const key = toEventSortKey({ eventDate: null, earliestGameTime: null });
|
|
expect(key).toBe("9999-12-31");
|
|
});
|
|
|
|
it("sorts ISO timestamp after same-day date-only string (mixed comparison)", () => {
|
|
// "2026-03-15" < "2026-03-15T..." lexicographically, so a date-only event
|
|
// on the same calendar day as a timed event correctly sorts before it
|
|
const dateOnly = toEventSortKey({ eventDate: "2026-03-15", earliestGameTime: null });
|
|
const withTime = toEventSortKey({ eventDate: "2026-03-15", earliestGameTime: "2026-03-15T14:00:00.000Z" });
|
|
expect(dateOnly < withTime).toBe(true);
|
|
});
|
|
});
|
|
|