Bulk remote assignments expire at midnight UTC on the chosen date, hours early for coordinators in the Americas #1711

Activity

1. joshunrau

   added

   BugType: existing behavior is wrongType: existing behavior is wrong

   Priority: MediumReal value; schedule normallyReal value; schedule normally

   Difficulty: LowIsolated change, about 2 hours or lessIsolated change, about 2 hours or less

   Area: Webapps/web (clinician-facing React SPA)apps/web (clinician-facing React SPA)

   on Oct 7, 2026
2. joshunrau commented on Oct 26, 2026

   

   joshunrau

   on Oct 26, 2026

   CollaboratorAuthor

   More actions

   Still reproduces on main (d86740e). Two corrections to the issue, and the fix has to reach more call sites than it lists.

   What the early instant breaks today

   The "link shows as expired at 20:00" part cannot happen yet: nothing in apps/gateway/src reads expiresAt (#1703). On main the early instant reaches only the email and the API's duplicate check, which stops counting the assignment as live from 19:59 EDT (assignments.service.ts:308). Once #1703 enforces expiry, participants are locked out at that time, so this should land before #1703 or with it. Rows created before the fix keep their stored instant. Nothing records the creator's zone, so they cannot be corrected.

   The single-assignment page is worse, not fine

   It does not submit a full date-time. kind: 'date' renders libui 6.16.1's DateField, whose mount effect runs setValue(new Date(inputValue)) on the YYYY-MM-DD string (DateField.tsx:22-31). The prefilled instant becomes 00:00 UTC at the start of the date shown. remote-assignment.test.tsx:199-209 pins this: the 2026-01-08T12:00Z prefill is submitted as new Date('2026-01-08'). In Montréal that assignment expires at 20:00 EDT / 19:00 EST on the evening before the date shown. The .min(new Date()) check (remote-assignment.tsx:182) runs on the same truncated value, so after that hour the page refuses tomorrow.

   The suggested fix moves two tables to D+1

   These show D today only because the stored instant is DT23:59:59.999Z:

   • apps/web/src/components/DeleteRemoteAssignments/DeleteRemoteAssignments.tsx:67-68
   • apps/web/src/routes/_app/datahub/subjects/$subjectId/assignments.tsx:136-137

   Both format createdAt and expiresAt with toBasicISOString. A local end of day set from Montréal is D+1T03:59:59.999Z, which both tables would show as D+1 to every viewer. The wizard's prefill at apps/web/src/routes/_app/group/remote-assignments.tsx:121-123 is a UTC date too.

   Plan

   1. Add apps/web/src/utils/local-date.ts with toLocalDateString(date) (toLocalISOString(date).slice(0, 10); resultCsvFilename already uses libjs's toLocalISOString) and endOfLocalDay(isoDate) (new Date(`${isoDate}T23:59:59.999`)). The rule "a bare date is the coordinator's day" then lives in one file, the only one to change if Timezone (GMT, EST) to be selected by group manager so dates can be displayed accurately #1604 ever picks a group zone.
   2. Use endOfLocalDay at useBulkAssignmentWizard.ts:61. On the single-assignment page, transform first and check after: z.coerce.date().transform((value) => endOfLocalDay(toBasicISOString(value))), then a .refine against Date.now() as $FutureDate does. The check then reads the clock at submit and tests the instant that is sent. toBasicISOString is right there only because DateField parses the field as UTC.
   3. Use toLocalDateString at bulk-assignments.ts:219, TimepointsStep.tsx:54, remote-assignments.tsx:121, and in both columns of the two tables. Set the date input's min (TimepointsStep.tsx:130) to tomorrow, since add and the button already refuse today (lines 58 and 139).

   Tests

   • Update useBulkAssignmentWizard.test.ts:185-196, which pins 2030-01-01T23:59:59.999Z, and remote-assignment.test.tsx:199-209. After the change, bulk-assignments.test.ts:259-269 passes or fails depending on the machine's zone, so build its input from local components as the resultCsvFilename test above it does.
   • apps/web/src/utils/__tests__/local-date.test.ts, with TZ=America/Toronto set in vi.hoisted.
   • e2e: a new describe in testing/src/specs/remote-assignments-wizard.spec.ts with test.use({ timezoneId: 'America/Toronto' }) and a winter date so the offset is fixed. D = 2030-01-15 must be stored as 2030-01-16T04:59:59.999Z, and the subject's Assignments tab must show 2030-01-15, which catches the table regression. The file's header says it creates no assignments, so update it. Do the same for the single-assignment page in testing/src/specs/remote-assignment.spec.ts. fix(web): align remote assignment table colors with datahub subject table #1811 and fix: resolve 26 low-difficulty issues, one commit each #1825 both add tests to remote-assignments-wizard.spec.ts.

   Related

   • Bulk remote assignment workbook upload reads dates of birth one day early in time zones east of UTC #1707 is the same UTC formatting of a local-midnight Date, in parseWorkbook (bulk-assignments.ts:301), and can reuse toLocalDateString.
   • With no TZ set on the API container, formatExpiryDate (mail.utils.ts:29-39) formats in UTC. After this fix it would email that D as "January 16, 2030 at 4:59 AM UTC", where today it says "January 15, 2030 at 11:59 PM UTC". A follow-up can send the browser's IANA zone in $SendAssignmentEmailData.
   • Not a duplicate of Timezone (GMT, EST) to be selected by group manager so dates can be displayed accurately #1604. This follows the rule from the comment there: display in the browser's zone, store UTC.
   • Upstream: libui's DateField calendar applies toBasicISOString to a local-midnight Date (DateField.tsx:58), so east of UTC, picking a day writes the day before into the field.

   _{Triage note written with Claude Code. Code references point at main @ d86740e.}