[pickers] Ignore milliseconds in mask logic

[alexfauquette]

Fix #6587

Maybe a better approach would be that date parsing ignore the milliseconds such that we can always use isEqual without having to worry about those miliseconds

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	505.9	1,122.2	559.7	754.98	221.046
Sort 100k rows	ms	603.5	1,239.1	1,239.1	942.22	231.337
Select 100k rows	ms	217.2	371	238.1	259.68	56.217
Deselect 100k rows	ms	194.5	307.5	217.5	236.74	42.213

Generated by 🚫 dangerJS against 0293d12

[oliviertassinari]

Would it make sense to close #6587 with the assumption that https://next.mui.com/x/react-date-pickers/time-field/ fixes the issue. Or have it on hold for once it eventually fixes it?

I'm asking because if the mask logic is eventually going away, I doubt we should fix a single bug related to it.

[alexfauquette]

Not being able to do backspace is a big bug, that's why I investigated. But yes, mask logic will be removed. That's why I did a quick fix without adding tests

[flaviendelangle]

I'm asking because if the mask logic is eventually going away, I doubt we should fix a single bug related to it.

Given that the migration from v5 to v6 is a big one, I would be in favor of doing this kind of fixes on v5.
We discussed it with Danail a few weeks back. For me, the situation of the pickers is not the same as the one from the grid (or the core). We did several big breaking migrations in the last year, all of this for a product that is below the rest of our components in term of quality.
We have a risk of loosing users with this kind of bug, people can be fed up with all the problems around the pickers.

[oliviertassinari]

The context for my comment wasn't really about this PR specifically, but to use it as a case study for a larger topic: the exploit vs. explore ressource allocation tradeoff. I think that the opposite of the points made could be argued:

1. The users that we are losing because of low quality are users that are willing to spend time to get a better implementation. Therefore I would assume that breaking changes we do is not a concern for them. To have a chance of them picking our new implementation we need to have it better than the alternatives, hence focus on it.
2. For existing bugs, I think that there a significant lag between changes we do, and when they benefits most (>80%) of the developers/end-users. If I had to estimate this lag, I would expect it to be 12+ months. We can a look at how long it takes for versions to be adopted to get some sense of this lag. So it might not get the impact we hope.

Personally 👍 to fix regressions, and 👍 to focus more on the new implementations ("focus" as saying no to the rest). For the pickers, specifically, I think that it would be great to iterate enough to reach the point where we are confident that once we make it stable, we can resist breaking changes long enough to reach >80% of adoption of v6.x. I don't think that we had this for a very long time, the versions has been spread.

[stem-ui]

This update introduced an issue when using Luxon.... Luxon equality takes into consideration the zone on its DateTime object. If I change the zone (e.g. through an accompanying zone selector component), this new equality check passes instead of fails, resulting in the rendered input string not updating.... any suggested workarounds?