feat(NcDateTimePicker): manual date input

[SebastianKrupinski]

☑️ Resolves

• Fix manual date input
• Re-parses manual date input if VueDatePicker fails
• Submits manual input on enter, tab or blur

🖼️ Screenshots

Recording.2026-04-18.210922.mp4

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable
• 2️⃣ Backport to stable8 for maintained Vue 2 version or not applicable

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.58%. Comparing base (7f48617) to head (0f5e4fc).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8443      +/-   ##
==========================================
+ Coverage   54.55%   54.58%   +0.02%     
==========================================
  Files         104      104              
  Lines        3400     3400              
  Branches      993      993              
==========================================
+ Hits         1855     1856       +1     
+ Misses       1306     1305       -1     
  Partials      239      239              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ShGKme]

Changing to feat, it introduces a new API.

[ShGKme]

In general, I'm unsure if it makes sense to have manual input without masking the value or explicitly specifying the format to the user.

It is clear when editing the current value, but quite unclear for new values.

What about disabling manual input at all?
cc @nextcloud-libraries/designers

[ShGKme]

We follow no-boolean-default props as more natural for HTML-styled template, allowing using boolean shortcut like in HTML.

<!-- default: true -->
<NcDateTimePicker />
<NcDateTimePicker :manualInput="false" />

<!-- default: false -->
<NcDateTimePicker />
<NcDateTimePicker noInput />

Suggested change

	/**
	* Enable or disable manual text input for the date picker.
	*
	* @default true
	*/
	manualInput?: boolean
	/**
	* Disable date text input
	*/
	noInput?: boolean

or

Suggested change

	/**
	* Enable or disable manual text input for the date picker.
	*
	* @default true
	*/
	manualInput?: boolean
	/**
	* Disable date text input
	*/
	noTextInput?: boolean

[SebastianKrupinski]

I left this as manualInput with a boolean on purpose, the underlying component actually supports:

• False
• True
• Options {
  enterSubmit = true,
  tabSubmit = true,
  }

This way the options can be implemented later without having multiple props and/or breaking functionality.

[susnux]

I agree with Grigorii here, we should stick with no boolean default rather than some underlying library.
In general we should not care about the library we wrap as we should define an interface and translate this to the library and not the otherway around.

[ShGKme]

This breaks accessibility by preventing using the data picker (the menu popup) via keyboard.

Previously, when the focus was in the input field, the menu could be open by typing or pressing Space, and then moving the focus to the menu by Tab

Now, Space acts as text input, and Tab goes to the next element, without opening the menu.

[SebastianKrupinski]

If a user can type in a date, this is much easier then trying to navigate a popup menu with a keyboard, so I don't seem this as a problem.

Alternatively we could disable the tab capture and a user can tab in to the menu.

I was actually thinking of disabling the popup menu on manual input, but thought is was a good visual feed back that the correct date is selected.

[ShGKme]

But not if the input value is changed significantly.

I enter 10/22/2026. Then I want to edit it changing the month, for example, 10 to 11. I go back and get Oct 22, 2026, where I actually need to change Oct to Nov.

[ShGKme]

It works with the date input and date-time input, but it breaks on the week input, the month input, the year input and the range input.

[SebastianKrupinski]

Oh, will look in to it.

[SebastianKrupinski]

In general, I'm unsure if it makes sense to have manual input without masking the value or explicitly specifying the format to the user.

This implementation supports multiple input formats, the one in the video above in not event a standard input format,

You can input,

YYYY-MM-DD

MMM DD YYYY

DD.MM.YYYY

DD/MM/YYYY

So forcing the user to use a specific format is not feasible, also since users are uses to using their localized format.

[ShGKme]

So forcing the user to use a specific format is not feasible, also since users are uses to using their localized format.

The first problem is specifying. Without knowing the supported format, a user just doesn't know in what format they should enter the data.

...in not event a standard input format

Which makes it even harder if a user didn't learn the "JS Date parser" format.
(Just leaving it here: https://jsdate.wtf)

You can input ...

... DD.MM.YYYY

I cannot, this is an Invalid date in JS.

DD/MM/YYYY

But it will be parsed as MM/DD/YYYY.
If I enter 02/03/2026 I get February 3rd, not March 2nd.

[kra-mo]

From the design side, it is tricky. Being able to manually enter a date is really valuable, but indeed, https://jsdate.wtf.

But I've also seen this done right. There are only so many possible date formats out there, and they are documented. People have wrote parsers before that cover 99.5% of what users will input, aside from typos. I'd like that.

But it's also fine to just have a placeholder in ISO 8601 for new values, like just the string YYYY-MM-DD, then the user can be expected to follow a format they see.