# Tempus Dominus v6: A TypeScript Date/Time Picker Without jQuery or Moment

> Tempus Dominus v6 is a TypeScript date/time picker whose only required runtime dependency is Popper2. The README states the project is no longer active and that new issues need sponsorship, so adoption means accepting a frozen feature set.

**Eonasdan/tempus-dominus** — This project is no longer active or supported.

- Repository: https://github.com/Eonasdan/tempus-dominus
- Website: https://getdatepicker.com
- Stars: 7,159 · Forks: 4,251
- Language: HTML
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/eonasdan-tempus-dominus

## What Tempus Dominus v6 replaces, and for whom

The picker solves a narrow, familiar problem: letting a user choose a date, a time, or both inside a web form, with the calendar positioned correctly against the input. The README describes v6 as "another major rewrite" over v5 and says it is written in TypeScript with modern browsers in mind. The dependency story is the selling point. Bootstrap, Moment.js and jQuery are no longer required; the README says Popper2 "is all that is required for the picker to position correctly." A jQuery provider exists for teams that still need it, and the README is blunt about that path: "If you still require jQuery (seriously, you should move off that asap)."

The audience is therefore front-end engineers maintaining forms in codebases that have already left jQuery behind, or teams migrating off Bootstrap's own date picker and Moment's locale machinery. It is not aimed at server-rendered applications that never load JavaScript, and it is not a scheduling or calendar component. It renders a control and returns a selected value. Anyone expecting recurrence rules, timezone conversion or booking logic is looking at the wrong layer.

One framing note matters before anything else. The README opens with a section titled "Paid support only" and states: "Please note that I'm moving on to other projects. New issues will need to be sponsored." The repository is not archived and the last push was on 2026-03-27, so the code is not abandoned in the GitHub sense. It is, by the maintainer's own description, no longer actively supported unless someone pays.

## How the v6 picker is put together

The package layout tells you most of what you need. package.json declares the npm name @eonasdan/tempus-dominus, with main pointing at dist/js/tempus-dominus.js, module at dist/js/tempus-dominus.esm.js, types at types/tempus-dominus.d.ts, style at dist/css/tempus-dominus.css and sass at scss/tempus-dominus.scss. That is a standard dual-format package: a UMD-style bundle for script tags, an ES module for bundlers, and a declaration file for TypeScript consumers.

Locales and plugins are separate build outputs rather than one monolith. The files array publishes src/js/locales/**/*.ts and src/js/plugins/**/*.ts alongside the compiled dist, and the build script runs build:plugins-and-locales through build/plugins.js. In practice that means locale data is opt-in: you import the specific locale module you need instead of shipping every language. The trade-off is that locale wiring is manual, and the README does not walk through it.

Positioning is delegated to Popper2, which is why the picker can attach to an input without Bootstrap's dropdown machinery. The rendering target is a normal DOM element, and the picker reads and writes a value through its own API rather than through a framework binding. There is no React, Vue or Angular adapter in the published files list; integration with those frameworks is something the consumer writes. That is a deliberate scope decision, and it is also the reason the package stays small.

## Installing Tempus Dominus and running the docs server

The README does not print an initialization snippet, so the only commands that can be reproduced exactly are the ones it does give. For anyone working on the library itself, the README documents installing packages with npm i, then either serving the generated documentation or running the full build with watchers.

```bash
npm i
```

```bash
npm run serve
```

The README states that npm run serve starts a web server and that you should navigate to http://localhost:3001/ to view the docs. The docs folder holds the generated documentation site, and the README warns not to modify it directly because it will be overwritten on build.

For continuous work, the README gives a second entry point and an explicit warning about running both at once.

```bash
npm start
```

According to the README, npm start runs the web server, the build, and watchers for the docs, styles and typescript, and you should not run npm run serve at the same time. The dist folder holds the built js and css files. Consumers install the published package under the scoped name @eonasdan/tempus-dominus; the package.json main field points at dist/js/tempus-dominus.js, the module field at dist/js/tempus-dominus.esm.js, and the style field at dist/css/tempus-dominus.css. If the popup renders but appears in the wrong place, the README names Popper2 as the only required dependency for positioning, so that is the first thing to check.

## The support model is the real constraint

Every technical question about this picker sits downstream of one fact: the README says new issues need sponsorship and that the maintainer is moving on to other projects. Priority support is offered "at an hourly rate," with installation help routed through a Discord server. This is not a project where you file a bug and wait. It is a project where you file a bug and then decide whether to pay, patch it yourself, or work around it.

The release cadence supports that reading. The most recent release listed is v6.10.4 from 2025-05-07, preceded by v6.10.3 on 2025-04-16 and v6.10.2 on 2025-03-11. Those are patch releases on a 6.10 line, not new feature work. The last push to the repository was on 2026-03-27. Nothing in the repository indicates a v7 roadmap.

There is a second, quieter failure mode: the documentation site. The README says the docs folder "contains the generated documentation site, don't modify this directly as it will be overwritten on build," and the homepage points at getdatepicker.com. The README does not document rollback, deprecation policy, or a migration path from v5 beyond calling v6 a rewrite. If your team needs a documented upgrade path with a support contract behind it, this is the wrong tool, and the honest alternative is a picker backed by a company that sells support.

## Alternatives and where the approach differs

The closest comparison in the search data is Bootstrap's own picker lineage. Tempus Dominus v6 explicitly drops Bootstrap as a required dependency, which means it can be dropped into a Tailwind or hand-rolled CSS project without pulling in Bootstrap's grid and JavaScript. A Bootstrap-native picker keeps you inside one design system and one upgrade cycle, at the cost of that coupling. If your application already loads Bootstrap, that coupling is cheap; if it does not, Tempus Dominus v6 avoids a dependency you would otherwise add solely for a calendar.

The second axis is Moment.js. The README states Moment is no longer required, which matters because Moment's locale bundles are large and its own maintainers have long signalled the project is in maintenance. A picker built on native Date and Intl avoids that weight but inherits the browser's date handling, including its quirks. Teams that need heavy date arithmetic beyond selection should keep a dedicated date library alongside the picker rather than expecting the picker to do it.

Native HTML input types are the third option and the one people forget. A plain <input type="datetime-local"> costs nothing, ships no JavaScript, and behaves differently in every browser, with inconsistent styling and no calendar popup on some platforms. Tempus Dominus v6 exists precisely because that inconsistency is unacceptable in a product where date entry is a primary interaction. If date entry is incidental, the native control is the better call.

## Licence and the cost of staying on v6.10.x

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. Nothing in the repository suggests a dual-licence arrangement or a commercial tier that changes those terms. Sponsorship and hourly support are offered separately from the licence; paying for support is not a licence purchase and does not change your redistribution rights.

Upgrade cost is the practical question. Because the package ships compiled dist files plus TypeScript sources and declaration files, a bundler-based consumer upgrades by changing one version in package.json and rebuilding. The risk sits in the two things the build generates separately: locales and plugins. The build:plugins-and-locales step compiles those from src/js/locales and src/js/plugins, and the published files array includes both source trees, so a locale you import by path could move between minor versions. Pin the exact version rather than a caret range if you depend on a specific locale module. This is not legal advice; read the LICENSE file in the repository for the operative text.

## Conclusion

Adopt Tempus Dominus v6 when you want a TypeScript-first picker with no jQuery or Moment dependency and you can pin the version you ship. Do not adopt it if you need a vendor to fix bugs on a normal support cadence: the README says new issues need sponsorship, and the last push was on 2026-03-27. Before committing, check the types/tempus-dominus.d.ts surface for the options you need, confirm the dist/css and dist/js paths your bundler will resolve, and decide whether you can maintain a fork if a defect lands in the locale or plugin build step.

## FAQ

### What is Tempus Dominus?

It is a date and time picker for JavaScript, written in TypeScript and aimed at modern browsers. Version 6 removed Bootstrap, Moment.js and jQuery as required dependencies, leaving Popper2 as the only requirement for positioning.

### What is a good Tempus Dominus alternative?

Bootstrap's own picker keeps you inside one design system and one upgrade cycle, while Tempus Dominus v6 avoids the Bootstrap dependency entirely. A native <input type="datetime-local"> is the zero-dependency option, though its styling and popup behaviour differ across browsers.

### How do I install Tempus Dominus v6?

The README documents installing packages with npm i, and the published package name is @eonasdan/tempus-dominus. Its package.json points main at dist/js/tempus-dominus.js and style at dist/css/tempus-dominus.css.

### Is Tempus Dominus still maintained?

The README states the maintainer is moving on to other projects and that new issues need to be sponsored. The last push to the repository was on 2026-03-27, and the most recent release listed is v6.10.4 from 2025-05-07.

### Does Tempus Dominus v6 still need jQuery or Moment?

No. The README states that Bootstrap, Moment.js and jQuery are no longer required dependencies, and that Popper2 is all that is required for the picker to position correctly. A jQuery provider exists for teams that still need it.

## Sources

- [Eonasdan/tempus-dominus on GitHub](https://github.com/Eonasdan/tempus-dominus)
- [License: MIT](https://github.com/Eonasdan/tempus-dominus/blob/master/LICENSE)
- [Project website](https://getdatepicker.com)
- [README](https://github.com/Eonasdan/tempus-dominus/blob/master/README.md)
- [Releases](https://github.com/Eonasdan/tempus-dominus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eonasdan-tempus-dominus