DaoSword/Time-Series-Forecasting-and-Deep-Learning: A Curated Paper Index, Not a Forecasting Toolkit
Resources about time series forecasting and deep learning.
At a glance
- What is it?
- This repository is a reading list: 638 paper entries with links, plus sections for benchmarks, datasets, courses and libraries. It ships no forecasting code, so its value depends entirely on how you use the index and how you handle the missing licence.
- Who is it for?
- Use this repository if you need a year-sorted entry point into time series forecasting literature and are willing to verify each paper's own artefact links yourself. Do not use it if you need runnable baselines, pinned dependencies, or a licence you can point at in a procurement review.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Repository Actually Is
The README opens by describing the project as a list of research papers focused on time series forecasting and deep learning, along with other resources such as competitions, datasets, courses, blogs and code. That sentence is the whole product. There is no forecasting model here, no training loop, no evaluation harness. The primary language is listed as Python, and the repository layout includes a scripts directory, but the visible Python is infrastructure for maintaining the index rather than code you would import into a forecasting pipeline.
The stated scope is narrower than the topic list suggests. The Scope section says the collection primarily focuses on time series forecasting, and that adjacent tasks (anomaly detection, classification, imputation, generation, representation learning) are covered as secondary material. If your problem is anomaly detection on sensor streams, this is not the index built for you. It is built for someone asking which architecture to try next for a forecasting horizon.
The audience is therefore a specific kind of reader: a researcher or engineer who already knows the domain vocabulary and wants a year-sorted map of what has been published. It is not an onboarding resource, and it does not pretend to be one.
The 638-Entry Index and the Script Behind the Count
The Papers section is the substance. The README shows a generated statistics block bounded by HTML comment markers reading PAPER_STATS_START and PAPER_STATS_END, with a note that it is generated by scripts/update_paper_stats.py and should not be edited manually. The table breaks the total down by year: 28 entries for 2026, 132 for 2025, 185 for 2024, 138 for 2023, 73 for 2022, 45 for 2021, 10 for 2020, 17 for 2019, and 5 each for 2018 and 2017, summing to 638.
That generated block is the most interesting design decision in the repository. A hand-maintained paper list rots quietly, because nobody notices when a year section drifts out of sync with reality. A script that rewrites a marked region means the count and the year table are derived, and the guard comment tells contributors where not to type. The trade-off is that the script becomes the thing you have to trust. The README does not describe what the script parses, whether it reads arXiv metadata or the markdown itself, or how it decides which year a paper belongs to. For a repository whose only artefact is an index, that is a meaningful gap.
Each entry follows a consistent shape: a linked title, an indented line with a date and first author followed by et al., and, where one exists, an indented link to official code. The 2026 entries illustrate the pattern, for example the Falcon-X entry pointing to arxiv.org/abs/2605.27286 with an official code link to the Falcon-TST repository, and the TimeRecipe entry dated 25 Mar 2026 with a link to the AdityaLab/TimeRecipe repository. Not every entry carries a code link, and the README does not explain the inclusion rule.
Reading the Year Sections Without Being Misled
The year-by-year organisation is useful and also easy to misread. The distribution is heavily weighted toward recent work: 2023 through 2026 account for the large majority of the 638 entries, while 2017 through 2020 together contribute 37. That shape reflects curation choices and the growth of the field, not a judgement that older work is unimportant. Classic sequence models and the early transformer-for-forecasting papers sit in the thin years, and a reader who skips straight to 2026 will miss the baselines that recent papers are still measured against.
Dates in the entries appear to be publication or revision dates rather than the year of first submission. The Characteristic Root Analysis entry, for instance, is listed under 2026 with a date of 13 May 2026 but an arXiv identifier in the 2509 range. The EventTSF entry shows the same pattern, dated 10 May 2026 under an identifier starting 2508. Anyone using the year headings as a chronology should read the date line rather than the heading. The README does not state which date convention is applied, so this is an inference from the entries themselves.
There is also a forward-looking edge to the list. The 2026 section contains 28 entries, and the README was last pushed in August 2026 according to the repository metadata. Whether those entries are final versions, preprints or workshop papers is not recorded. Treat the most recent year as a moving target that the maintainer is still filling in.
Benchmarks, Datasets and the Rest of the Sections
Beyond papers, the table of contents lists Applications, Benchmarks, Blogs, Competitions, Courses, Libraries, Datasets, Books, Repositories and Tutorials. The Benchmarks section is populated with four entries: FinTSB, described as a financial time series benchmark; the GIFT-Eval leaderboard hosted on Hugging Face; TIME, described as task-centric and aimed at zero-shot evaluation of time series foundation models; and QuitoBench, which the README says has balanced coverage across eight trend, seasonality and forecastability regimes.
That benchmark list is short enough to be a deliberate selection rather than an attempt at completeness, and the four entries point at genuinely different evaluation philosophies. FinTSB is domain-bounded to finance. GIFT-Eval is a hosted leaderboard. TIME targets zero-shot foundation model evaluation. QuitoBench organises difficulty by statistical properties rather than by application domain. For a reader deciding how to evaluate a model, that quartet is more informative than a longer undifferentiated list would be.
The Applications section, by contrast, contains a single entry: Nixtla's TimeGPT, described as a generative pre-trained forecasting model. One entry under a top-level heading is a signal about how much curation effort has gone into that part of the repository. The README as supplied does not show the contents of Blogs, Competitions, Courses, Libraries, Datasets, Books, Repositories or Tutorials, so nothing can be said about their depth. The headings exist; the material behind them is not visible in the excerpt.
Getting the Repository and Using the Generated Stats
There is no installation section, no package metadata and no published release. The metadata shows no releases retrieved and no homepage, so the only documented way to obtain the material is to clone the default branch:
git clone https://github.com/DaoSword/Time-Series-Forecasting-and-Deep-Learning.git
The only script named in the README is scripts/update_paper_stats.py, invoked by whoever maintains the list to regenerate the block between the PAPER_STATS_START and PAPER_STATS_END markers. If you fork the repository to track a subfield, that script is the piece you would need to read before editing the paper sections, because the comment inside the generated block states plainly that it should not be edited manually. Editing inside the markers will be overwritten the next time the script runs.
The README gives no Python version, no dependency list and no invocation example for the script. Anyone forking this to maintain a private reading list should expect to read the source before running it. The repository also carries a set of badge images in the header, including commit activity, last commit, closed issues, forks and stars, but the README does not describe any workflow that consumes them.
The Missing Licence and the Maintenance Question
The licence is listed as unknown. That is the single most consequential fact about this repository for anyone considering reuse. Without a licence file, the default position under most copyright regimes is that no rights are granted beyond what the hosting platform's terms allow, which means copying the curated list into an internal wiki, a commercial product or a training corpus is legally unclear. The README does not address licensing at all, and the metadata does not supply an identifier. This is a factual observation about the repository state, not legal advice; if reuse matters to you, get a lawyer's read rather than a reviewer's.
Maintenance cost is harder to judge than it looks. The generated stats block suggests an automated path for the counts, which lowers the cost of keeping the year table honest. The per-entry work of adding a paper, its date, its author line and its code link is not automated as far as the README shows. A list that adds roughly 185 entries in a single year, as the 2024 row indicates, requires steady attention to stay current. The repository is not archived and was pushed in August 2026, so it is active. What is not visible is whether more than one person is doing the work, or what happens to the list if that stops.
Stale code links are the predictable failure mode. Papers get renamed, repositories move, and an index that records a code URL at publication time will accumulate dead links. The README does not describe any link-checking step.
Where a Curated List Loses to Papers With Code or a Framework Docs Site
The obvious alternative is Papers with Code, which links papers to implementations and, where available, to reported results on standard datasets. The difference in approach is structural. Papers with Code derives its links from a database and surfaces leaderboard numbers alongside each paper. This repository is hand-curated markdown organised by year, with code links added per entry at the maintainer's discretion and no results table at all. If you want to know which model currently tops a benchmark, the curated list will not tell you; you will follow its link to GIFT-Eval or TIME and read the leaderboard there.
A second alternative is the documentation of a forecasting framework such as the one behind TimeGPT, which the README lists under Applications. Framework documentation gives you an API, a quickstart and versioned behaviour. This repository gives you a bibliography. They answer different questions, and confusing them is the main way a reader will be disappointed. A third option, for someone who wants runnable baselines rather than pointers, is to pick a single well-maintained model repository from the code links and work from its own README, which will carry the dependency pins and training commands this index deliberately omits.
The honest comparison is that this repository competes on editorial selection and on the year-by-year view, not on completeness, not on freshness guarantees, and not on reproducibility.
Who Should Clone This and What to Check First
Adopt it if you are starting a literature review on forecasting architectures and want a pre-sorted starting point that spans 2017 to 2026, with code links attached where the maintainer found them. Adopt it if you are tracking the shift toward foundation models for time series, since the 2025 and 2026 sections are dense with entries on that theme, including Falcon-X, CoRA, Time Tracker, TimeCAP and the position paper on agentic forecasting. Adopt it as a fork base if you want to maintain a narrower list and are willing to read scripts/update_paper_stats.py first.
Do not adopt it if you need a dependency you can pin, a model you can train, or a licence you can cite in a compliance review. Do not adopt it as your only source for benchmark numbers, because it records no results. Do not adopt it if your task is anomaly detection or classification, since the Scope section places those outside the primary focus and the visible content reflects that.
Three things to verify before relying on it. First, the license field on the repository page, since it currently reads unknown and that governs what you may copy. Second, the behaviour of scripts/update_paper_stats.py, because the integrity of the 638-entry count and the year table depends on it and the README does not document its inputs. Third, the code links in whichever year section you care about, by opening a sample of them, since the README describes no link-checking process and dead implementation URLs are the failure this format invites.
Editorial conclusion
Use this repository if you need a year-sorted entry point into time series forecasting literature and are willing to verify each paper's own artefact links yourself. Do not use it if you need runnable baselines, pinned dependencies, or a licence you can point at in a procurement review. Before adopting it as a team reference, check the license field on the repository page, read scripts/update_paper_stats.py to confirm how the paper count is maintained, and spot-check three entries from the most recent year against their arXiv listings.
Community notes