Skip to content

fix: prevent selecting event end time before start time - #1216

Open
leahpeker wants to merge 13 commits into
mainfrom
fix-1208-end-date-scroll-bound
Open

leahpeker wants to merge 13 commits into
mainfrom
fix-1208-end-date-scroll-bound

Conversation

@leahpeker

Copy link
Copy Markdown
Collaborator

Fixes #1208

Summary

  • Added a min prop to the DateTimePicker component to constrain the minimum allowed date/time
  • When selecting an end datetime, the picker now disables calendar days before the start date
  • On the same day as start datetime, the time picker has a minimum time constraint via the <input type="time" min=...> attribute
  • End datetime picker in EventFormBasics now passes the start datetime as the min value

Details

The issue was that users could scroll (on mobile datetime pickers) to select an end time earlier than the start time. This is now prevented at the UI level:

  • Calendar dates before start are disabled
  • Time input gets a min attribute when on the same day to prevent scrolling to earlier times
  • Backend validation (existing code) still validates that end >= start as a safety check

…mePicker

disablePast and min were two separate code paths computing the same
thing (a lower bound for the calendar). min now doubles as the floor
when disablePast is set, defaulting to today.
floor was only ever read once, immediately truncated into floorStart.
Compute floorStart directly from minDate/today instead.
Every real call site already passed it explicitly. Flip the default
and drop the now-redundant prop from callers.
No caller ever passed disablePast={false} — it was dead configurability.
The picker now unconditionally floors at min's day, or today.
minTime only fired when an explicit min prop was passed, so a picker
with just the implicit "disable past" floor (no min) let you pick
today's date and then any time, including ones already past. Compute
a real minInstant (min, or now) so the time floor always applies on
the floor day.
<input type="time" min=...> only flags rangeUnderflow for form
validation — it never blocks the value from being entered or
scrolled to in the field itself. Confirmed in-browser: typing 09:00
into today's time field was accepted with no visual feedback, even
though "now" was 8:47pm. Clamp in onChange instead of trusting the
browser to enforce min interactively.
Clicking a calendar day alone (without touching the time field)
defaulted to noon regardless of min, so picking today for the "ends"
picker with a start already later than noon produced an end time
before the start. Extract clampToMin and apply it in both onSelect
and the time input's onChange. Confirmed live: start 9:51pm, click
today on ends with no other input -> ends now clamps to 9:51pm
instead of defaulting to noon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

End date scroll

1 participant