A raw timestamp is nearly useless to most ML models as-is — its real predictive power comes from the calendar and cyclical structure hidden inside it, which has to be explicitly extracted before a model can use it.
What to Extract From a Single Timestamp
import pandas as pd
df = pd.DataFrame({"purchase_time": pd.to_datetime(
["2024-03-15 14:30:00", "2024-07-04 09:15:00", "2024-12-25 21:45:00"]
)})
df["year"] = df["purchase_time"].dt.year
df["month"] = df["purchase_time"].dt.month
df["day_of_week"] = df["purchase_time"].dt.dayofweek # 0=Monday ... 6=Sunday
df["hour"] = df["purchase_time"].dt.hour
df["is_weekend"] = df["day_of_week"].isin([5, 6]).astype(int)
print(df)"is_weekend" alone can be a surprisingly strong feature for anything consumer-behavior related — weekend purchases, support ticket volume, and app usage often follow genuinely different patterns than weekdays, a pattern the raw timestamp column hides completely from a model.
Cyclical Encoding — Fixing a Subtle Bug
Treating "month" as a plain number (1–12) tells a linear model that December (12) and January (1) are 11 units apart — when in real, cyclical time, they're adjacent (1 month apart). This is fixed with sine/cosine encoding:
import numpy as np
df["month_sin"] = np.sin(2 * np.pi * df["month"] / 12)
df["month_cos"] = np.cos(2 * np.pi * df["month"] / 12)
# Now December and January map to nearby points on a circle, not distant numbers on a lineThis same trick applies to hour-of-day (24-hour cycle) and day-of-week (7-day cycle) — anywhere a numeric encoding would otherwise falsely imply a "start" and "end" to something that actually wraps around.
Features That Require a Second Timestamp
df2 = pd.DataFrame({
"signup_date": pd.to_datetime(["2024-01-01", "2024-03-15"]),
"churn_date": pd.to_datetime(["2024-04-01", "2024-03-20"]),
})
df2["tenure_days"] = (df2["churn_date"] - df2["signup_date"]).dt.days
print(df2)Practical Use Cases
- Fraud detection — unusual purchase hour, weekend/holiday timing
- Churn prediction — customer tenure, recency of last activity
- Demand forecasting — seasonality (month, day-of-week), which cyclical encoding directly supports
Common Mistakes
- Feeding a raw timestamp directly into a model — most algorithms have no way to meaningfully use it as a single unprocessed number.
- Using plain integer month/hour encoding without cyclical (sin/cos) transformation for models sensitive to numeric distance, like linear regression or KNN.
- Computing a "days since X" feature using a reference date that wouldn't actually be known at prediction time (a common, subtle form of leakage in time-based features).
Interview Relevance
Q: "Why would you sine/cosine encode 'month' instead of using it as a plain integer?" Because a plain integer encoding implies month 12 and month 1 are 11 units apart, when they're actually adjacent in cyclical calendar time — sin/cos encoding maps months onto a circle, correctly placing December next to January.
Practice Question
You're building a model to predict restaurant order volume. Propose three date-time features you'd extract from a raw order timestamp, and explain what each one might capture.
