fix: use text input for date variables to respect Joplin date format … by sh1vam31 · Pull Request #146 · joplin/plugin-templates

sh1vam31 · 2026-02-25T19:53:31Z

Fixes #112 — Template dialog UI should respect the date locale settings

Description

The native HTML5 <input type="date"> in Chromium (used by Electron/Joplin) hardcodes its internal representation and ignores Joplin's Tools → Options → Date format setting. Furthermore, native date inputs cannot be themed consistently to match Joplin's dark/light modes and lack quick year navigation.

Fix

Custom Date Picker (Flatpickr): Integrated Flatpickr custom date picker styled using Joplin theme CSS variables (--joplin-background-color, --joplin-color, etc.) in src/views/flatpicker-overrides.css.
Locale-Aware Formatting: Automatically maps Joplin's Moment date formats to Flatpickr formats so the placeholder and picker format match the user's preference.
Year Dropdown: Replaced default arrows with a quick year <select> dropdown (±10 years) for easier navigation.
Robust Error & Empty Input Handling:
- Leaving the date field empty safely returns an empty string without crashing.
- Standard date formats (e.g., ISO YYYY-MM-DD) are normalized into the user's configured format.
- Non-date inputs fall back to raw input rather than throwing, preventing the dialog inputs from being lost.
Asset Pipeline: Flatpickr dependency is managed via package.json and copied directly from node_modules into the distribution bundle via Webpack.

sh1vam31 · 2026-02-28T11:01:58Z

@alondmnt, @nishantwrp, Kindly review this PR

nishantwrp · 2026-02-28T11:08:56Z

+        // Use type="text" instead of type="date" to bypass Chromium's OS-locale
+        // date picker, which ignores Joplin's date format setting (issue #112).
+        // The placeholder shows the user's configured format as a hint.
+        return `<input name="${encode(this.name)}" type="text" placeholder="${encode(this.dateFormat)}" pattern="\\d{4}-\\d{2}-\\d{2}"></input>`;


isn't there an option to give locale to <input type="date">?

Thanks for the question, I did look into this — unfortunately, Chromium ignores the lang attribute and all HTML locale hints for . The display format is controlled purely by the OS locale, not the page settings. This is a known limitation even in Electron.

Switching to type="text" with a placeholder showing the user's Joplin date format was the only reliable workaround I found. Happy to explore any other approach if you have one in mind!

I see. I think text would be inconvenient for the users when compared to a native date-picker.

Maybe, we can explore some small custom date picker component (maybe https://www.npmjs.com/package/react-datepicker). Maybe need some additional work to comply with joplin theming but maybe that is something that can be done in follow-up.

sh1vam31 · 2026-02-28T19:35:32Z

Updated! I've replaced the type="text" workaround with a flatpickr custom date picker. It respects the user's Joplin date format, shows a native-feeling calendar UI, supports both clicking and typing, and adapts to Joplin's theme.

joplin#112) - Replaced <input type="date"> with a flatpickr-powered custom date picker - flatpickr is initialized in datepicker.js using the user's configured Joplin date format (e.g. YYYY-MM-DD), converted from moment.js to flatpickr tokens - Added a year dropdown so users can jump to any year quickly (±10 years) - The calendar theme is adapted to Joplin's dark/light CSS variables - Date format is injected into each DateCustomVariable via setDateFormat() called from parser.ts before the dialog is rendered

nishantwrp · 2026-03-01T07:34:20Z

    overflow: auto;
 }
+
+/* ── Flatpickr: make the calendar fit the dialog and match Joplin theme ── */


can you move these to src/views/flatpicker-overrides.css

nishantwrp · 2026-03-01T07:36:40Z

 }

-th, td {
+th,


can you revert these linting changes, helps keep the diff small and focus on whats actually changed

nishantwrp · 2026-03-01T07:37:57Z

+        // so the placeholder matches their configured format (fixes issue #112).
+        for (const variable of Object.values(variableObjects)) {
+            if (variable instanceof DateCustomVariable) {
+                variable.setDateFormat(this.utils.getDateFormat());


why can't this be done inside "src/variables/types/date.ts"?

alondmnt · 2026-03-12T01:47:20Z

Hi @sh1vam31, friendly reminder on the outstanding review comments: the CSS split, linting revert, and moving the format injection into date.ts. Let us know if you need any help.

sh1vam31 · 2026-09-21T04:00:06Z

Hi @nishantwrp and @alondmnt, thanks for the feedback.

I've updated the PR and addressed all review comments:

CSS Split: Moved Flatpickr-specific styles into src/views/flatpicker-overrides.css.

Linting: Reverted the unrelated th, td formatting changes in webview.css.

Format Injection: Refactored the code so DateCustomVariable now dynamically fetches the date format at render time (via utils passed to toHTML), removing the need for parser.ts to inject it.

Conflicts: Merged master and resolved all conflicts (including keeping the new aria-label addition).

Let me know if it looks good.

alondmnt · 2026-10-03T12:33:55Z

Thanks @sh1vam31!

What should happen when the date field is left empty, or someone types something that doesn't match the format? As it stands processInput throws, so the whole template fails with the parsing error and the dialog input is lost. Try leaving the field blank, or typing the date in a wrong format, and see what you get. The old native input never put the plugin in that state, so it's worth handling deliberately.

flatpickr is added to package.json, but the code uses the copied flatpickr.min.* files in src/views. Could you use one or the other?

Also, I believe that the PR description needs an update.

sh1vam31 · 2026-10-14T10:59:13Z

Hi @alondmnt, thanks for the review.

I've updated the PR based on your feedback:

Empty / Invalid Date Handling: Handled empty inputs so they safely evaluate to an empty string "" without crashing. Added fallback handling that normalizes alternative date formats (such as ISO) into Joplin's configured format, and falls back to raw input on invalid text so template parsing never crashes or loses user input. Added unit tests for these cases in tests/parser.spec.ts.
Asset Management: Removed the duplicated flatpickr.min.* vendor files from src/views/ and configured Webpack's CopyPlugin to copy them directly from node_modules/flatpickr/dist/ into dist/views/ on build.
PR Description: Updated the PR description to accurately reflect the Flatpickr integration, theming, and edge-case handling.

nishantwrp requested changes Feb 28, 2026

View reviewed changes

sh1vam31 force-pushed the fix/date-variable-respects-locale-settings_#112 branch 2 times, most recently from 3d1d498 to 9778666 Compare February 28, 2026 19:34

sh1vam31 force-pushed the fix/date-variable-respects-locale-settings_#112 branch from 9778666 to 3681032 Compare February 28, 2026 19:39

nishantwrp requested changes Mar 1, 2026

View reviewed changes

extract CSS, refactor date format logic, resolve conflicts

070f7a7

sh1vam31 requested a review from nishantwrp September 18, 2026 05:40

fix: handle empty/invalid date inputs and copy flatpickr via webpack

240ccc7

muditagrawal2007 mentioned this pull request Oct 27, 2026

fix(#169): keep the date that was picked in the date picker #187

Closed

Navigation Menu

Repository navigation

fix: use text input for date variables to respect Joplin date format … - #146

fix: use text input for date variables to respect Joplin date format …#146
sh1vam31 wants to merge 3 commits into
joplin:masterfrom
sh1vam31:fix/date-variable-respects-locale-settings_#112

sh1vam31 commented Feb 25, 2026 •

edited

Loading

Uh oh!

sh1vam31 commented Feb 28, 2026

Uh oh!

nishantwrp Feb 28, 2026 •

edited

Loading

Uh oh!

sh1vam31 Feb 28, 2026

Uh oh!

nishantwrp Feb 28, 2026

Uh oh!

sh1vam31 commented Feb 28, 2026

Uh oh!

nishantwrp Mar 1, 2026

Uh oh!

nishantwrp Mar 1, 2026

Uh oh!

nishantwrp Mar 1, 2026

Uh oh!

alondmnt commented Mar 12, 2026

Uh oh!

sh1vam31 commented Sep 21, 2026

Uh oh!

alondmnt commented Oct 3, 2026

Uh oh!

sh1vam31 commented Oct 14, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

sh1vam31 commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Fix

Uh oh!

sh1vam31 commented Feb 28, 2026

Uh oh!

nishantwrp Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sh1vam31 Feb 28, 2026

Choose a reason for hiding this comment

Uh oh!

nishantwrp Feb 28, 2026

Choose a reason for hiding this comment

Uh oh!

sh1vam31 commented Feb 28, 2026

Uh oh!

nishantwrp Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

nishantwrp Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

nishantwrp Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

alondmnt commented Mar 12, 2026

Uh oh!

sh1vam31 commented Sep 21, 2026

Uh oh!

alondmnt commented Oct 3, 2026

Uh oh!

sh1vam31 commented Oct 14, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sh1vam31 commented Feb 25, 2026 •

edited

Loading

nishantwrp Feb 28, 2026 •

edited

Loading