Time Series Forecasting · Part-1

Time Flies — But First, You Have to Catch It

A beginner’s guide to taming time series data: what it actually is, how to structure it in Python, and why your computer has no idea what “2019 Jan” means.

Let me start with a confession: when I first encountered the phrase time series analysis, I thought it just meant “data with a date column.” Spreadsheets have dates all the time. What’s the big deal?

The big deal, as I would learn the hard way, is that time is not just context — it’s structure. And if you don’t teach your computer that structure, you’ll spend three weeks building a beautiful model that predicts the past slightly worse than a coin flip.

This chapter is about the fundamentals — the boring-but-essential anatomy of time series data. Think of it as learning to read music before you compose a symphony. And yes, we’re doing all of this in Python, so if you’ve been traumatised by R syntax before, congratulations: you’re safe here.

What Actually Makes Data “Time Series” Data?

A regular dataset is a table. A time series dataset is a table that tells a story — one where the order of rows is not an accident but a deliberate chronicle of something changing over time.

To turn a plain DataFrame into a proper time series, you need to define exactly two things:

1. Observations — the numbers you actually care about (medicine costs, prison populations, website visits).

2. A time index — a chronological timestamp attached to every observation, telling Python “these rows have a sequence; respect it.”

In R, there’s a special object called a tsibble built for exactly this. In Python, we achieve the same thing by giving our DataFrame a DatetimeIndex. It's a small change with enormous consequences — suddenly, pandas knows that a missing row isn't a data entry error, it might be a missing point in time.

# From this (just a CSV with a date column):
df['date'] = pd.to_datetime(df['date'])

# To this (an actual time series):
df = df.set_index('date')

# Now pandas treats rows as a sequence in time, not just items in a list.

The Calendar Is Not Your Friend (Until You Make It One)

Here’s something that will haunt you if you ignore it: your computer cannot read “2019 Jan.” It sees a string. A useless, ambiguous string — the same kind of object as “banana” or “tuesday” or “please work”. It has no idea that “2019 Jan” comes before “2019 Feb,” that there are 31 days in January, or that the concept of a “month” exists.

“2019 Jan” means nothing to a machine. It’s just banana with numbers in it.

The fix? Convert your date strings into actual time objects using pd.to_datetime() or pd.PeriodIndex. Once you do that, pandas can reason about time: it can resample, fill gaps, align multiple series, and detect when your data skips a month.

And crucially — time series data must have regular intervals. If your data is monthly, every row must represent exactly one month. If it’s quarterly, every row is a quarter. No skipping.

Keys: When One CSV Contains 10,000 Time Series

When you open a dataset of, say, Flipkart/Amazon order data, you’re not looking at one time series.

You’re looking at hundreds of time series stacked together.

The data might track orders by:

• State (Karnataka, Maharashtra, Delhi…)
• Category (Electronics, Fashion…)
• Customer Type (New, Returning)
• Payment Mode (UPI, COD, Card)

“Karnataka + Electronics + New + UPI” is one time series.

“Maharashtra + Fashion + Returning + COD” is a completely different time series.

# Option 1: groupby
group = df.groupby(['State', 'Category', 'Customer_Type', 'Payment_Mode'])

# Option 2: MultiIndex
df = df.set_index(['Date', 'State', 'Category'])

# Pull one specific timeline
blr_electronics = df.loc[(slice(None), 'Karnataka', 'Electronics'), :]

Seasonal Periods: How Often Does History Repeat?

A seasonal period is the number of data points it takes for a pattern to fully repeat. Every forecasting model you’ll ever use needs to know this number — because without it, the model is essentially trying to detect a rhythm it’s never been told exists.

Notice that weekly data has 52.18 periods, not a neat 52. That decimal exists because of leap years. It’s a small detail that causes large headaches if you round it away when specifying seasonality to your model.

High-frequency data is where things get genuinely interesting. Minute-by-minute data doesn’t have one seasonal pattern — it has three simultaneously:

# Minute-by-minute data has multiple overlapping seasons:

hourly_cycle  = 60      # 60 minutes per hour
daily_cycle   = 1_440   # 60 × 24 minutes per day
weekly_cycle  = 10_080  # 60 × 24 × 7 minutes per week

# You must tell your model WHICH cycles to look for.
# It will not figure this out on its own.

Why this matters

If you’re modelling electricity demand, people use more power in the morning and in the evening (daily cycle), and less on weekends (weekly cycle). A model that only sees one cycle will misread the other as noise — and give you forecasts that are confidently, systematically wrong.

What Comes Next

We’ve covered the anatomy: observations, time index, keys, and seasonal periods. These are the bones of every time series problem you’ll ever work on. Get them wrong and your model is building on sand; get them right and you have a foundation you can actually trust.

In Part-2, we’ll start looking at time series — decomposing them into trend, seasonality, and residual noise. You’ll learn that “the data goes up and down” is a complete failure of analysis, and that every time series is actually a superposition of simpler, interpretable signals hiding inside.

Reference

Hyndman, R.J. & Athanasopoulos, G. (2021). Forecasting: Principles and Practice, 3rd ed. OTexts. Available free at otexts.com/fpp3 —