Thank you for creating this issue! 🙏
I can confirm that the problem is evident, it's also an issue with moment-timezone.
However, dayjs adapter seems to be working correctly as seen in this demo.
Could you confirm if you must use Luxon in your application?
I'll try investigating the issue in more depth to understand if it could be some issue on our end, or if is it a problem on both Luxon and Moment adapters. 🤷

Confirming that this seems to be the expected behavior for Luxon.
It's a known limitation that is documented.
Here are some relevant issues: moment/luxon#1089, moment/luxon#1278.

I've found a workaround for DigitalClock, which should avoid the problem of DST reliance.
The fix is somewhat logical because both MultiSectionDigitalClock and TimeClock do not have such a problem, because of how they are implemented. 👍

@LukasTy thank you so much for the response and taking the time to whip up such a nice demo of the adapters!

However, I still believe the issue is not specific to any of the Adapters. From your demo, the bug is still evident on both "Fall-back" and "Spring-forward" pickers for Dayjs.

Fall Back ends at 22:30:

Spring Forward includes 00:00 & 00:30 for the next day:

The Problem (I think)

The Code in DigitalClock that creates the timeOptions (similar to your demo TimeIn30Increments) expects there to be 24 hours in every day. This is correct for all dates in a year, except when dates use a timezone that respects Daylight Savings. When a DST timezone is used, the following two days of the year do not have 24 hours:

• The date in which clocks "fall back", one hour is added to the day. Therefore, the Fall Back Date respecting DST actually has 25 hours. This year that happens on November 5th (every year the exact date is different).
• The date in which clocks "spring forward", one hour is removed from the day. Therefore, the Spring Forward Date respecting DST actually has 23 hours. Next year that happens on March 10th (every year the exact date is different).

My belief that this is the problem is from how I see timeOptions being used in DigitalClock. Here's my brief understanding:

• timeOptions is an array of Adapter-Specific Dates
• The timeOptions array is created with the startOfDay (midnight AM of the valueOrReferenceDate) as the first item in the array
• Then for every time step minus 1 (since startOfDay is already in the array) in a 24 hour day, a new date is added to the array.
• The important part likely causing the bug is 24 * 60.
• So from what I can see here, timeOptions will always be a list of every timeStep starting from startOfDay to 24 hours later
• Later in the component, timeOptions (AKA "24 hours of time steps") is used in a map to render each time option.

Possible solution

Rather than using 24 as the "golden rule" for how many hours there are in a day, we could try something like the following:

const timeOptions = React.useMemo(() => {
  let timeStepOptions = [];
  const startOfDay = utils.startOfDay(valueOrReferenceDate);
  let nextTimeStepOption = startOfDay;
  while (utils.isSameDay(valueOrReferenceDate, nextTimeStepOption)) {
    timeStepOptions.push(nextTimeStepOption);
    nextTimeStepOption = utils.addMinutes(nextTimeStepOption, timeStep);
  }
  return timeStepOptions;
}, [valueOrReferenceDate, timeStep, utils]);

I have added the following updates to your awesome Demo to reflect this:

• TimeIn30Increments includes the code above with comments describing variables accessible in DigitalClock
• I used TimeIn30Seconds to also show "Spring Forward" times for each Adapter
• Updated demo here: https://codesandbox.io/s/intelligent-moore-ztlzpf?file=/src/demo.tsx:915-933

Screenshot of updated Demo:

Note that the pickers themselves still show the bug (because the bug originates inside of Digital Clock). The displayed "TimeIn30Increments" does now show the expected times for each adapter.

Also, apologies for my primitive code! I'm sure there is a more optimal and concise way to do that. I mainly wanted to illustrate an option.

@LukasTy I added it to the board
If you think it's a non trivial topic to close, I would be in favor of estimating it and prioritizing it quickly given how old it is 👍