Preparing Input Features for Machine Learning Models

In this time series setup, the only input feature is the date and time, and the output is the number of rentals in the following three hours.

Programming

A Model That Sees Only a Clock

Imagine you want a model to predict how many bicycles will be rented in the next three hours. The only information you give the model is the moment in time at which a count was recorded. There is no weather column, no station name, and no price. Everything the model can learn about rentals must come from the time itself.

This is the setup for a time series prediction task. The input feature is the date and time, and the output the model tries to predict is the number of rentals in the following three hours. In this article we follow one timestamp through a conversion that turns it into a number a model can read, then trace how a whole hourly sequence becomes a single feature column.

One Row, One Timestamp, One Target

In this setup each row of the training data holds a timestamp such as 2015-08-01 00:00:00 and a target value that counts rentals. Nothing else describes the row. The timestamp is the input, the count is the output the model must learn to predict, and the window of three hours comes from the DataFrame used in the source example.

Definition

A time series input feature is a feature derived from the date and time at which each observation occurred. In this setup it is the only input, and the model's target is the number of rentals in the following three hours.

What goes into the model, what comes out, and how one input timestamp connects to the three-hour window of rentals it predicts.

Because the timestamp is the only clue, two rows that share the same hour of the day would look identical to the model apart from their dates. The raw date-time text is also not directly a number. Before any learning can happen, the timestamp has to be turned into a numeric value. The standard integer representation for this is POSIX time.

Counting Seconds from 1970

Computers often store a date as a single integer rather than as separate fields for year, month, day, hour, and minute. This integer is POSIX time, defined as the number of seconds since January 1970 00:00:00. That starting instant is also called the beginning of Unix time. A single integer therefore carries the whole timestamp, and it always increases as time moves forward.

Where a given timestamp falls on a line that starts at 1970 and counts seconds forward, and how many seconds lie between two timestamps.

Tracing the Value of One Midnight

Work through a single timestamp by hand. The moment is 1 August 2015 at midnight in UTC. The POSIX value is the number of seconds that have elapsed since 1 January 1970 00:00:00. Count the full days first. From 1 January 1970 up to 1 January 2015 there are 16436 days, since 45 years contain 45 times 365 days plus 11 leap days. From 1 January 2015 to 1 August 2015 there are 212 more days. That gives 16648 days in total.

Worked example

Predicting the POSIX value of 1 August 2015 at midnight

What integer does POSIX time assign to 1 August 2015 at 00:00:00 UTC?

1
Count the elapsed days
From 1 January 1970 to 1 August 2015 there are 16648 days, made up of 16436 days up to 2015 and 212 days through July.
2
Convert days to seconds
One day has 86400 seconds, so 16648 days is 16648 times 86400.
3
Read the result
The product is 1438387200, which is the integer that represents the moment.

Result

The POSIX value is 1438387200 seconds.

What do you think happens?

Midnight on 1 August 2015 is 1438387200. Before looking at the answer, predict the POSIX value for 01:00 the same day.

Reveal answer

Answer:

1438390800

One hour is 3600 seconds, and 1438387200 plus 3600 equals 1438390800.

Converting a Timestamp in Python

Python can do the counting for you. A datetime object has a timestamp() method that returns its POSIX value. The source emphasizes one detail: attaching timezone.utc keeps that value consistent across machines, so the same moment yields the same integer wherever the code runs. Read the code below and notice which part describes the moment and which part performs the conversion.

python

from datetime import datetime, timezone

# The moment: 1 August 2015 at midnight, in UTC
moment = datetime(2015, 8, 1, 0, 0, tzinfo=timezone.utc)

# The conversion: ask for the POSIX value in seconds
print(moment.timestamp())

from datetime import datetime, timezone

# The moment: 1 August 2015 at midnight, in UTC
moment = datetime(2015, 8, 1, 0, 0, tzinfo=timezone.utc)

# The conversion: ask for the POSIX value in seconds
print(moment.timestamp())

Output (expected)

1438387200.0

Notes on the code

The datetime call describes the moment: year, month, day, hour, minute, and time zone.
The tzinfo argument attaches UTC so the value does not depend on the local machine.
timestamp() performs the conversion and returns the count of seconds since 1 January 1970 00:00:00.

The output is a float, 1438387200.0, because timestamp() returns seconds with a fractional part. The integer value is the same number. The model needs only this single numeric column, so the exact type matters less than keeping the timezone consistent.

Human-Readable Text Versus One Integer

The same moment can be written two ways. A formatted date-time string is easy for people to read but is made of several fields that a model cannot use directly as one number. The POSIX integer packs all those fields into a single count that increases steadily as time moves forward.

Property	Formatted date-time	POSIX integer
Example for 1 Aug 2015, midnight UTC	2015-08-01 00:00:00	1438387200
Number of fields	Several (year, month, day, hour, minute, second)	One
Direction as time moves forward	Text changes in several places	Value always increases
Suitability as a single model input column	Needs conversion first	Ready as a numeric column

Two representations of the same moment

From Hourly Timestamps to a Feature Column

A time series contains many timestamps, not one. Take the three hourly moments that follow midnight on 1 August 2015: 01:00, 02:00, and 03:00. Convert each one to its POSIX value, then collect the results as rows. Each row holds a single feature, so each inner list is one row of the feature matrix.

Which integer each hourly timestamp maps to, and how consecutive hours map to integers that rise by the same step.

python

from datetime import datetime, timezone
import numpy as np

# The three hourly moments after midnight on 1 August 2015
moments = [datetime(2015, 8, 1, hour, tzinfo=timezone.utc) for hour in range(1, 4)]

# Convert each moment to its POSIX value
values = np.array([m.timestamp() for m in moments])

# One row per example, one column for the single time feature
X = values.reshape(-1, 1)

print(X)
print(np.diff(X.ravel()))

from datetime import datetime, timezone
import numpy as np

# The three hourly moments after midnight on 1 August 2015
moments = [datetime(2015, 8, 1, hour, tzinfo=timezone.utc) for hour in range(1, 4)]

# Convert each moment to its POSIX value
values = np.array([m.timestamp() for m in moments])

# One row per example, one column for the single time feature
X = values.reshape(-1, 1)

print(X)
print(np.diff(X.ravel()))

Output (expected)

[[1.4383908e+09]
 [1.4383944e+09]
 [1.4383980e+09]]
[3600. 3600.]

Notes on the code

The list comprehension builds the three hourly moments in UTC.
timestamp() turns each moment into its POSIX value.
reshape(-1, 1) gives the two-dimensional layout a model expects: rows are examples and the single column is the feature.
The np.diff call checks that consecutive values differ by exactly 3600 seconds.

The printed differences are 3600 each time. That is the signature of a regular hourly series after conversion: a column of integers that rises at a steady step. The -1 tells NumPy to infer the number of rows from the data, and the 1 makes the single time feature occupy one column. If the differences were irregular, or one value were far from what you calculated by hand, the timestamps or their conversion would deserve a second look.

Mistakes Beginners Make with Converted Timestamps

Common mistake
Assuming a timestamp means the same thing everywhere
What it looks like
Converting datetime(2015, 8, 1, 0, 0) without a time zone and running the code on two machines set to different zones.
Why it fails
A naive datetime carries no zone, so the integer it produces can depend on where the code runs.
Do this instead
Attach timezone.utc to the datetime before calling timestamp().
Common mistake
Trusting a conversion without checking its output
What it looks like
Feeding the integer column straight into a model without printing it or taking differences.
Why it fails
A wrong timezone or a misread date produces a plausible-looking number that silently corrupts the feature.
Do this instead
Compare one converted value against a hand calculation, and confirm that the steps between consecutive hours are 3600.
Common mistake
Forgetting that the integer alone hides the hour and weekday
What it looks like
Expecting the model to learn the daily cycle from the POSIX column alone.
Why it fails
The integer does not state the hour of day or the day of the week in any explicit way.
Do this instead
Treat the integer as one valid representation and check how well it captures the patterns in rentals before relying on it.

Practicing the Hourly Conversion

EASY

Using the same method, predict the POSIX values for 04:00 and 05:00 on 1 August 2015, then state the step between them. Check your answer by running the code with those hours.

Hints

Start from 1438398000, the value for 03:00.
One hour is 3600 seconds, so each following hour adds 3600.

Your attempt (not saved)

MEDIUM

Change the code so that it converts the three hours before midnight on 1 August 2015 instead of the three hours after. Predict whether the step between consecutive values is still 3600 before you run it.