fix: timezone-aware contest scheduling and display - #94
Merged
Conversation
Add endsAt as a required UTC ISO datetime field in the zod testSchema so the end time is validated as a proper timestamp rather than a locale-dependent time string. Also expose endsAt as an optional field on the Test interface for edit-form population.
…imezone Previously, the "Ends At" time string was parsed and applied via setHours() inside a Next.js Server Action (UTC on server), so an admin in IST entering "01:30 PM" would store 13:30 UTC instead of 08:00 UTC. Fix by computing endsAt as a UTC ISO string entirely in the browser (info-card.tsx), consistent with how startsAt is already handled. The server action now receives and validates two UTC ISO strings directly, with no timezone-sensitive arithmetic. On edit, the stored UTC endsAt is converted back to the admin's local time display using the browser's Intl API.
…breviation Replace date-fns format() calls with toLocaleString/toLocaleTimeString using timeZoneName:'short', so every displayed timestamp automatically converts the stored UTC value to the viewer's browser timezone and shows the abbreviation (e.g. "10:00 AM IST", "4:30 AM UTC"). Add a LocalTime client component for server-rendered pages (result, submissions) where timezone conversion must happen on the client. Also show the admin's local timezone name in the test creation form so they know which timezone their inputs are interpreted in.
Rajaykumar12
force-pushed
the
feat/timezone-handling
branch
from
June 6, 2026 10:19
f12605f to
84a7808
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
setHours()inside a Next.js Server Action (which runs in UTC), so an admin in IST entering "01:30 PM" would store13:30 UTCinstead of08:00 UTC(the correct equivalent)info-card.tsxderivesendsAtas a UTC ISO string using the browser's local timezone, consistent with howstartsAtwas already handled; the server action receives two UTC ISO strings and does no timezone mathendTimeis converted back to the admin's local time display via the browser'sIntlAPI, not the server's clocktoLocaleStringwithtimeZoneName: 'short'so each viewer sees times in their own local timezone with the abbreviation (e.g. "10:00 AM IST" for India, "4:30 AM UTC" for a UTC viewer)<LocalTime>client component: Used in server-rendered pages (result, submissions) where timezone conversion must happen on the client after hydrationAsia/Kolkata) so they know how their inputs are interpretedTest plan