I still have a few small details to check, but feel free to review. I don't expect any big changes in the code.

The datepicker supports range selection which links two datepickers so that they limit each other's max/min values.

I think for usecases like room booking but also the accommodation field in the regform, we'll definitely need this - and since you're working on the regform, maybe tackling the accommodation field next would be nice. I recommend trying out the current behavior there, because I think it's more than just "two linked pickers" - we show both pickers at once, and a nice feedback of the range you selected / are selecting:

In case of the accommodation field there's also some slightly more tricky login regarding the valid dates, because unlike the typical "min/max number of nights" many date pickers use, we actually have a range of valid arrival and departure dates (which can, of course, be implemented by dynamically generating the mix/max dates like we do in the current version of that field).

I've addressed the feedback from this PR as far as the single-date picker goes. @ThiefMaster Would you like me to tackle the accommodations picker in this PR as well, or do it in a separate PR once this is merged? Makes no difference to me.

Would you like me to tackle the accommodations picker in this PR as well, or do it in a separate PR once this is merged? Makes no difference to me.

Let's see/decide once this one is ready to merge. Separate PR is probably fine though... But let's iron out all the remaining problems with the initial date picker first! :)

Now that this is merged, if you could look into the feature needed for the accommodation field that would be great! Because I think those features might already make it possible to replace the date pickers in other places (e.g. Room Booking) with your new one. And once we can get rid of react-dates for good, we unblock quite a few big JS library upgrades (including using a more recent React version).

Another interesting part to look into may be the time picker. It's used in the regform when you have a date field and add time format in its config, but we have many other places where it's used as well - and while it works OK-ish most of the time, its usability is not really great, and probably its accessibility is pretty poor as well. So I'd love to eventually replace it with something nicer.

Another interesting part to look into may be the time picker. It's used in the regform when you have a date field and add time format in its config, but we have many other places where it's used as well - and while it works OK-ish most of the time, its usability is not really great, and probably its accessibility is pretty poor as well. So I'd love to eventually replace it with something nicer.

I think the idea is to use the new combobox to create a more accessible time picker

Let's use a separate thread for this discussion, I think it's weird to have a possibly extended discussion under this closed PR ;) --> #6387

When testing the new datepicker elsewhere, I noticed that the styling of its disabled version is quite different from that of SUI elements. Would it be possible to make the gray-out more noticeable like in the SUI elements?

This is mostly used while a form is being submitted, so I think/hope strong contrast is less important there...

Can you give me the StR for that scenario, and also maybe push a branch with the integration that you're doing?

What does StR mean in this context? This particular screenshot was just me testing after I noticed that it looked differently than the other fields while submitting (=disabled).

Actually, I just realized that this particular screenshot may still get some regform CSS (this test was in the "CERN site access" module of one of our custom plugins where I tried changing the birth date field to your new date picker). In other places it still looks slightly different but way better overall:

For this particular screenshot I'll add a commit on top of #6394 to test it easily. Replicating the previous screenshot's example w/o having to use that other plugin (which is a bit cumbersome to setup) takes a bit more time. I'll look into it later or tomorrow.

FYI: date picker does not explicitly style its input at all. It takes the appearance of the default input style in the context. Or it should anyway. If the context only uses SUI inputs and doesn't provide any input styling or provides input styling that doesn't match SUI, the datepicker input style will not match SUI.

Also FYI: contrast guidelines does not apply to disabled anything.

What does StR mean in this context?

How do I reach the screen you are testing on?

The easiest way is to add two date fields to the regform w/ different formats, and then use e.g. this to disable one of them:

diff --git a/indico/modules/events/registration/client/js/form/fields/DateInput.jsx b/indico/modules/events/registration/client/js/form/fields/DateInput.jsx
index e388c9fdf3..137696d74c 100644
--- a/indico/modules/events/registration/client/js/form/fields/DateInput.jsx
+++ b/indico/modules/events/registration/client/js/form/fields/DateInput.jsx
@@ -129,7 +129,7 @@ export default function DateInput({
         name={htmlName}
         component={DateInputComponent}
         required={isRequired}
-        disabled={disabled}
+        disabled={disabled || friendlyDateFormat === 'MM/DD/YYYY'}
         dateFormat={friendlyDateFormat}
         timeFormat={timeFormat}
         validate={validateDateTime}

So the immediate goal is to match the disabled state, yes? Also, do you need this ASAP, or is it ok if I first finish the combobox?

not urgent at all, it's very minor in fact. And it seems like we're setting disabled in the regform in some weird way so I'll have a closer look there in case that's what's causing this problem altogether (AFAIK in SUI usually the surrounding div.field has the disabled class and then the input inside as well, and when only one of them is set then the styling may be off)

Ok, I'm probably spending tomorrow and maybe Monday working on the combobox. I need to rework it so it supports disabled options, and also fix the extra field so it actually works and uses the same ComboBox as the main field.

In case you didn't see my message on Matrix: A colleague noticed a bug in Safari: When clicking one of the navigation arrows in the dialog to move between months, clicking them just closes the dialog.