sktime: a unified Python interface for forecasting, classification and detection

The problem sktime solves: one interface, many time series tasks

Python's time series tooling is split by task. A forecasting library exposes a fit-and-predict loop over a horizon. A classification library expects labelled series and returns class probabilities. Anomaly and changepoint detection libraries return index positions. Each comes with its own data structures, its own splitting logic, and its own idea of what a validation set looks like. If you want to compare a forecasting model against a classification model on the same series, or reuse a tuned pipeline across two tasks, you end up writing glue code that has nothing to do with the problem you are solving.

sktime's stated objective is to enhance the interoperability and usability of the time series analysis ecosystem, and the mechanism is a unified interface for distinct but related time series learning tasks. The README lists forecasting, time series classification, clustering, anomaly and changepoint detection as the tasks currently covered. It is aimed at engineers and researchers who already know scikit-learn and want the same estimator, fit, predict vocabulary applied to series data. It is not aimed at someone who wants a single ARIMA call and nothing else.

How the unified interface works across forecasting and classification

The design follows scikit-learn's estimator contract. You construct an estimator, call fit, then call a task-specific predict method. The difference is what those methods accept and return. Forecasters take a series and a forecasting horizon and return predictions indexed to that horizon, while classifiers take a panel of labelled series and return labels or probabilities. Because both sides of that contract are standardised, composite tools that already exist in scikit-learn can be pointed at time series estimators: pipelining, ensembling, tuning and reduction.

Reduction is the part worth understanding. The README describes tools for composite model building that let users apply algorithms designed for one task to another. A classifier can be turned into a forecaster, or a forecaster into a feature source for a classifier, because the interface is uniform. The repository also ships dedicated time series algorithms rather than relying purely on wrappers. Alongside those, sktime provides interfaces to related libraries including scikit-learn, statsmodels, tsfresh, PyOD and fbprophet. That distinction matters in practice: a native estimator and a wrapped third-party estimator behave differently when dependencies are missing or when the underlying library changes its API.

Installing sktime and running a first forecasting example

The package is published on PyPI and conda-forge, and the README links both badges. The pyproject file declares requires-python as >=3.10,<3.15, so check your interpreter before installing. The project's own Makefile shows an editable install into the active environment, which is the pattern contributors use:

python3 -m pip install -e . --user

For normal use rather than development, install from PyPI. The README links the PyPI project page, and the package name is sktime:

python -m pip install sktime

The repository ships worked notebooks under examples/, including examples/01_forecasting.ipynb, examples/02_classification.ipynb, examples/03_transformers.ipynb and examples/07_detection_anomaly_changepoints.ipynb. Those are the fastest way to see the intended call pattern for each task. The README also points to Binder, which runs the examples directory in a browser without a local install, and to the tutorials page at sktime.net. The documentation does not present a single canonical quickstart snippet in the README itself, so the notebooks are the reference for a first real use.

If you are working from a checkout, the Makefile also exposes test targets. Running the unit suite is a separate step from installing, and the target copies .coveragerc and setup.cfg into a testdir before invoking pytest:

make test

Where sktime gets in the way

The unified interface is a layer, and layers cost something. If your problem is a single univariate series and a single forecasting model, sktime adds estimator classes, horizon objects and task vocabulary that a direct call to the underlying library would not require. The README is explicit that one of sktime's roles is to provide interfaces to other libraries, which means in many cases you are running a wrapper around code you could call yourself. When something goes wrong inside that wrapper, the traceback is longer and the failure is further from the source.

Dependency handling is the second constraint. Because sktime interfaces to statsmodels, tsfresh, PyOD and fbprophet among others, those packages are not all core dependencies. The pyproject file notes that the core dependency set is kept minimal. The Makefile even carries a dedicated target, test_softdeps, described as running unit tests to check soft dependency handling in estimators. That target exists because soft dependencies are a real failure surface: an estimator can be listed and importable at the registry level while failing at fit time if the optional package is absent. The README does not document rollback or version pinning for those optional packages, so you should treat the estimator overview as the place to confirm what a given estimator actually needs.

sktime compared with statsmodels and prophet

The honest comparison is not about which library forecasts better. It is about scope. statsmodels is a statistics library with a strong econometric and inference tradition, and its time series models are native to it. If you need coefficient estimates, confidence intervals and diagnostic tests, statsmodels is the direct route, and sktime's own README lists it as one of the libraries sktime interfaces to. Prophet is a single forecasting procedure with its own decomposition model, packaged as a self-contained tool. The README lists fbprophet among the interfaced libraries, so in sktime you can call Prophet through the same estimator API as everything else.

That is the actual difference in approach. statsmodels and Prophet each answer one class of question well and make no claim beyond it. sktime does not try to replace them; it standardises how you call them and what you get back, so that a Prophet forecaster, a statsmodels forecaster and a native sktime forecaster can be tuned with the same search object and compared in the same benchmark. The repository reflects that ambition in its examples directory, which includes examples/04_benchmarking_forecasters.ipynb and examples/04_benchmarking_classifiers.ipynb alongside examples/04_m4_competition.ipynb. If you never intend to compare models across libraries or tasks, the standardisation buys you little.

Maintenance, releases and the BSD-3-Clause licence

The repository is not archived, and the last push was on 2026-09-10, so the codebase is being changed. Recent releases are v1.0.1 on 2026-06-11, v1.0.2 on 2026-07-26 and v1.1.0 on 2026-07-28. The README leads with a note that version 1.1.0 is out and links the changelog. The upgrade cost is the distance between those point releases: v1.0.1 to v1.0.2 to v1.1.0 in roughly seven weeks means patch and minor changes arrive quickly, and the changelog is the only reliable record of what moved. The project is governed by a Community Council according to a comment in pyproject.toml, and the README points to GOVERNANCE.md and a roadmap document, so direction is documented rather than implicit.

The licence is BSD-3-Clause, declared in pyproject.toml as a file reference to LICENSE and shown in the README badge. That is a permissive licence, which matters if you are embedding sktime in a commercial product, but the licence covers sktime itself. Several of the libraries sktime interfaces to carry their own licences, and some of those differ. If you depend on a wrapped estimator rather than a native one, check the wrapped library's terms separately. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt sktime if you need one API across forecasting, classification, clustering and detection, or you want to reuse scikit-learn style tuning and pipelining on time series. Do not adopt it if you only need one forecasting model and no cross-task comparison, since the interface layer adds concepts you will not use. Before committing, check the estimator overview for the specific algorithm you need, confirm it is implemented natively rather than through an interface to another library, and read the changelog between v1.0.1 and v1.1.0 to see what moved.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. sktime/sktime on GitHub