nldates-obsidian: natural language dates in Obsidian, now unmaintained

What the plugin actually does inside the editor

NLDates is a set of Obsidian commands for working with dates and times, built around one idea: you type a phrase and the plugin rewrites it. Typing @today and pressing Enter expands the text to the current date. Pressing Shift at the same time keeps the original phrase as an alias, so @today becomes a wikilink whose display text is still today while its target is a concrete date. The README describes this as expanding dates using natural language inline within the editor view.

The parse engine is chrono, pulled in as the chrono-node dependency. That library is what recognises the phrases in the first place, and the plugin adds Obsidian-shaped output on top: a wikilink, a standard markdown link, or plain text, depending on which command you ran. A second dependency, obsidian-daily-notes-interface, is what lets the plugin target the daily note format your vault uses rather than assuming a filename pattern.

The important behavioural rule sits early in the documentation: if a date is not recognised, the link will not be created. There is no error, no placeholder and no literal text left behind. That is the right failure mode for a text-rewriting plugin, since it means an unparsed phrase simply stays as prose, but it also means a typo in a date expression is invisible until you notice the missing link.

Autosuggest settings and the trigger character

The autosuggest has three settings, and the table is worth reading because two of them change how the plugin behaves in a way that can surprise you. Enable/Disable is a global toggle, on by default. Trigger phrase sets the character or characters required to open the autosuggest, defaulting to @. Insert as link decides whether dates are inserted as wikilinks, which is the default, or as something else.

The trigger phrase setting is the one to think about. It is not fixed to @, so a vault that already uses @ for mentions can move the trigger to something else, and a vault that uses @ for people while still wanting date expansion has to pick a different character. Since the setting takes characters rather than a fixed symbol, several trigger characters can be set at once, which turns the autosuggest into a general expansion trigger rather than a date-specific one. The trade is that a broad trigger fires on every keystroke that starts with it, and the plugin then competes with Obsidian's own suggestions for the same keystrokes.

Insert as link is the other setting with visible consequences. With it off, dates are inserted as plain text, which is the right choice in a vault where daily notes are not wikilinks, and the wrong choice if you rely on the link for navigation.

The command set, and the formats it writes

The plugin registers a group of Obsidian commands, and the defaults column of the table tells you exactly what each one writes. Insert current date writes YYYY-MM-DD. Insert current time writes HH:mm. Insert current date and time writes YYYY-MM-DD HH:mm. These three use the format specified in the settings menu, so the defaults are the starting point rather than a fixed behaviour.

The parse commands are more interesting. Parse natural language date replaces the selected text with an Obsidian link to the parsed date, defaulting to [[YYYY-MM-DD]]. Parse natural language date (as link) produces a standard markdown link, [selected text](YYYY-MM-DD). Parse natural language date (as plain text) writes the bare date. Parse natural language time replaces the selection with a timestamp, HH:mm, and the documentation notes that standard forms such as now, in 15min, in 1h and 5min ago all work.

A documented convenience: for single-word dates such as today, tomorrow or friday, the parse command can be used without selecting the word first, and the same trick works for compact forms like Nov9 or 25Dec. That is what makes the command usable at the cursor rather than only on a selection.

Hotkeys are unset by default since version 0.4.1, and you add them under Settings > Hotkeys by filtering for Natural Language Dates. The reason for the change is a sensible one, since binding keys globally by default would collide with other plugins, but it means a fresh install has no shortcut until you configure one.

The nldates URI action opens a daily note from outside Obsidian

Beyond the editor, the plugin registers an Obsidian URI action called nldates, with the form obsidian://nldates?day=<date here>. The day parameter takes a natural language date string, and the documentation warns that space characters have to be encoded appropriately following the Obsidian URI guidance. A second parameter, newPane, opens the note in a new pane and defaults to yes.

This is the feature that makes the plugin useful in a larger system. A calendar application, a task manager or a shell script can construct a URI that opens the right daily note directly, with no copy and paste step, and the natural language input means the caller does not have to know the vault's date format or filename convention. The date format in the daily note still has to match what the daily notes settings expect, and that is where the obsidian-daily-notes-interface dependency does its work.

The URI action also means the plugin has a small attack surface that the editor commands do not. Anything that can hand a URL to the operating system can trigger a note to open, and the day parameter is parsed by the same natural language engine. Nothing in the documentation describes input validation or a whitelist of accepted formats for that parameter.

A fork dependency and a plugin build with no installer

The package manifest is small and tells you more than the README does about how this is put together. It is a TypeScript project built with Rollup, with three scripts defined:

    "lint": "eslint . --ext .ts",
    "dev": "rollup --config rollup.config.js -w",
    "build": "rollup --config rollup.config.js"

The build output is main.js, which is the file Obsidian loads as a plugin, alongside manifest.json and versions.json at the top of the repository. The devDependencies pin the toolchain at TypeScript 4.7.4, Rollup 2.60, ESLint 8.2.0 and Prettier 2.4.1, with obsidian set to latest.

The dependency worth looking at is chrono-node, which is not a registry version but a GitHub reference to liamcain/chrono. Pinning a parser to a fork rather than a published release means the parser code is a moving branch rather than an immutable artifact, and it means a build depends on that fork remaining available. The other runtime dependency, obsidian-daily-notes-interface, is pinned to 0.9.4, a specific published version, which is the more conventional choice and a reminder that the two dependencies carry very different upgrade risk.

None of this is a defect. It is the shape of a small, focused plugin built by one person, and it is also the argument for the community fork that the README now recommends, since a fork can re-pin these dependencies and fix the ones that matter.

The project points you somewhere else now

The most important line in the README is an important callout at the top: this repository is no longer maintained, and a community-maintained fork is available, with Natural Language Dates Redux offered as another option.

The release history is consistent with that. The most recent tagged release is 0.6.2 from 2023-12-01, before that 0.6.1 from 2022-02-05, and 0.6.0 from 2021-11-16. The last push to the repository was on 2026-09-09, so the tree has changed since the last release even though no new version was published, which is exactly the state you should expect from a project where the released artefact and the branch have drifted apart.

For an engineer, the consequence is a version-check discipline. A vault that installed 0.6.2 years ago is running code from 2023, with a dependency set from that era, and the documentation a user reads today may describe settings that the installed build does not have. The project is MIT licensed, so the licence is not the constraint; continuity of the code is.

The alternative worth comparing is the community fork rather than a different plugin. A fork keeps the same command names, the same autosuggest and the same URI action, so migrating is a matter of installing a different build, while switching to a different natural language date approach means re-learning the trigger and the command set.

Editorial conclusion

nldates-obsidian is worth keeping if your vault is full of daily notes and you are comfortable installing a plugin whose parser dependency is pinned to a fork on GitHub, since the natural language parsing is the part that saves real typing and the obsidian-daily-notes-interface integration is what keeps daily note links consistent. It is not worth installing from this repository directly, because the project states it is no longer maintained and points to a community fork. Before switching, check whether the community fork or Natural Language Dates Redux covers the commands you actually use, confirm the version in your plugin list matches the one whose release notes you read, and keep the change to a plugin you can remove by deleting the folder, since a plugin that rewrites text as you type is one you want to be able to disable quickly.

Frequently asked questions

Official sources

1. argenos/nldates-obsidian on GitHub
2. Issues
3. License: MIT
4. README
5. Releases