chore: add loose restrictions to date time text field

[Xazin]

Closes: #6788

This just adds some loose restrictions to the Date and Time text fields in the Date Picker.

This is done to help the user write the correct format. It's not completely enforced according to the date format, but does limit the user a bit more.

24-hours - Can only enter 5 characters (12:34) and only enter numbers and :
12-hours - Can enter AM and PM as well (12:34 AM) 8 characters

Date field - Can only enter 12 characters (Unsure if should limit it to 10) and allows ., -, and / characters other than numbers.

PR Checklist

• My code adheres to AppFlowy's Conventions
• I've listed at least one issue that this PR fixes in the description above.
• I've added a test(s) to validate changes in this PR, or this PR only contains semantic changes.
• All existing tests are passing.

[richardshiue]

Hmm... I'm not sure I actually like this change. For some users, this helps to give an input that will be correctly parsed. On the other hand, for others (or it's me only) this could be a hindrance. If I put an extra space somewhere in the input, I could hit the length limit and have to go back and correct that before entering my last few characters.

Also, this prevents users from entering dates in the way that is most comfortable to them. The unit tests are failing since the tests are using human-readable date inputs (Nov 30, 2024) to take advantage of the date parsing library we're using

[Xazin]

Hmm... I'm not sure I actually like this change. For some users, this helps to give an input that will be correctly parsed. On the other hand, for others (or it's me only) this could be a hindrance. If I put an extra space somewhere in the input, I could hit the length limit and have to go back and correct that before entering my last few characters.

Also, this prevents users from entering dates in the way that is most comfortable to them. The unit tests are failing since the tests are using human-readable date inputs (Nov 30, 2024) to take advantage of the date parsing library we're using

I see what you mean, but how would users know they can type Nov 30, 2024? We don't have a way for them to discover this right?

The hint in the textfield show the "correct" format, so users would assume that to be followed.

We can remove the formatter for the Date field if you prefer?

[richardshiue]

We don't have a way for them to discover this right?

You're right. We don't need to though, since if we let users enter dates however they want and we parse them correctly every time, it'll give them flexibility and convenience.

We can remove the formatter for the Date field if you prefer?

Yes I think that would be better

[Xazin]

We don't have a way for them to discover this right?

You're right. We don't need to though, since if we let users enter dates however they want and we parse them correctly every time, it'll give them flexibility and convenience.

We can remove the formatter for the Date field if you prefer?

Yes I think that would be better

Done, sorry about the delay :)