Time Series Prediction and Feature Representation

Gaps in time show up as gaps in the integer values. A model that receives these numbers can detect that one observation came before another and by how much, without any date-specific logic.

Programming

Why a Model Cannot Read a Calendar Date

A time series prediction model needs numbers. A column of datetime values, such as calendar dates with clock times, cannot be fed to a model directly. The question this article answers is how a column of datetime values can become a numeric feature, and what that conversion does to the information the model actually sees.

The running example pairs a time index with a count of bike rentals recorded at each time. The rental count is the target: the value the model should learn to predict. The time index is the input that needs to be represented as a feature. These two roles must stay separate. The target stays exactly as it is, and only the time index is transformed.

What do you think happens?

Before reading further: if the time index is transformed into a feature, which part of the data should change, the rental counts (the target) or the time index (the input)?

The rental counts, because the model predicts them
Only the time index, because the target stays as it is

Reveal answer

Answer:

Only the time index changes. The target stays as it is.

The target is the value the model learns to predict, so it is kept separate. The conversion only applies to the datetime index, which is the input the model needs as numbers.

POSIX Time as a Count of Seconds

The conversion relies on POSIX time, a way of storing dates that is common on computers. POSIX time is a count of seconds. The count starts at January 1, 1970, at 00:00:00, which is also the starting point of Unix time. Every moment after that origin receives a single whole number equal to how many seconds have passed since then.

Definition

POSIX time stores a date as the number of seconds elapsed since January 1, 1970, at 00:00:00, which turns a timestamp into one ordered integer.

How does each datetime map to a position on a single number line measured from the epoch, so that later dates always get larger integers?

The timeline makes the counting idea concrete. The origin sits at zero, and each following day adds 86400 seconds, because a day has 24 hours of 3600 seconds each: $24 \times 3600 = 86400$. Since the spacing between consecutive days stays constant, equal gaps in time become equal gaps in the feature.

Key point

Gaps in time show up as gaps in the integer values. A model that receives these numbers can detect that one observation came before another and by how much, without any date-specific logic.

Because each later timestamp receives a larger integer, the representation preserves the order of the data. The value is a plain integer, so a model can work with it using ordinary arithmetic. That is exactly what the conversion in this article is designed to allow.

Tracing the Three-Stage Conversion

The conversion takes place in two lines of code. The first line separates the target values from the datetime index. The second line turns each timestamp in the index into an integer and arranges those integers as a column. The single expression that builds the feature hides three separate transformations: strftime, astype, and reshape. They run in this order.

python

X = index.strftime("%s").astype("int").reshape(-1, 1)

X = index.strftime("%s").astype("int").reshape(-1, 1)

Notes on the code

index: the datetime index holding the timestamps
strftime("%s"): formats each timestamp as text (a string representation)
astype("int"): converts that text into integers
reshape(-1, 1): arranges the integers as a single column

What is the value and shape of the data after each step, and at which step does the unexpected result first appear?

The pipeline shows the order in which the data changes shape and type. Because the three steps are chained, the final output alone does not reveal which stage went wrong. The method for locating a fault is to inspect the output of each stage in order, starting from the datetime index and moving forward until the value or shape stops matching what you expected.

From a Text Format to an Integer Column

The strftime step produces text: a formatted string representation of each timestamp. The astype step then changes the type of those values to integers. The text and the integer are different things, even though they describe the same moment. The integer is the underlying number that the feature needs, and astype is what makes that change.

Before

index.strftime("%s")

Each timestamp is held as formatted text, so the values are not yet numbers a model can do arithmetic with.

After

index.strftime("%s").astype("int")

Each timestamp is held as an integer count of seconds, ordered so that later times have larger values.

Feature Matrix Shape After Reshape

After the integers are produced, they form a one-dimensional sequence with one entry per timestamp. The reshape(-1, 1) call rearranges that sequence into a two-dimensional column. The first dimension counts the rows, one per observation. The second dimension has size 1, because the feature matrix holds exactly one feature. The result is a feature matrix of shape $(n, 1)$, where $n$ is the number of timestamps.

How does a 1-D array of N timestamps become an (N, 1) feature matrix, and what does each dimension mean?

Worked example

Shape of X for five timestamps

Suppose the datetime index holds 5 timestamps, one per observation. What is the shape of X after the conversion?

1
Count the observations
The index holds 5 timestamps, so n = 5 rows.
2
Identify the feature count
There is one feature, the integer time column, so the second dimension is 1.
3
Apply the reshape pattern
The reshape produces a matrix of shape (n, 1), which is (5, 1).

Result

X has shape (5, 1): five rows and one column.

Mistakes Beginners Make with the Conversion

Common mistake
Treating the strftime output as a number
What it looks like
Using the result of strftime("%s") directly for arithmetic, as if it were an integer.
Why it fails
strftime produces formatted text, not an integer. The type change happens in astype.
Do this instead
Apply astype("int") before relying on the values as numbers.
Common mistake
Converting the target along with the time index
Why it fails
The target is the value the model should predict. Transforming it changes what the model is learning.
Do this instead
Separate y from the datetime index first, then convert only the index.
Common mistake
Judging the final result without checking each stage
Why it fails
The three chained steps hide where a wrong value or shape first appeared.
Do this instead
Print or inspect the output after strftime, after astype, and after reshape, and stop at the first stage that does not match expectations.
Common mistake
Expecting a one-dimensional result from reshape(-1, 1)
Why it fails
The reshape call exists to produce a two-dimensional matrix with one column.
Do this instead
Expect shape (n, 1), where n is the number of timestamps.

Predicting and Checking the Feature Matrix

EASY

A datetime index holds 12 hourly timestamps for bike rentals. Before running any code, predict the shape of X after the conversion, then check your answer by inspecting the output after the reshape stage.

Hints

Count the timestamps first. Each one becomes one row.
reshape(-1, 1) gives the matrix exactly one column because there is one feature.

Your attempt (not saved)

MEDIUM

A conversion returns the right number of rows, but the values look like text strings such as dates formatted as characters. Which stage of the pipeline has the problem, and what would you check first?