Calendar and Datetime Features

A timestamp like 2026-01-02 09:31:00 means nothing to a model as a raw number — most libraries would either reject it or silently convert it to some huge integer count of seconds since 1970, a number with no useful relationship to the return you're trying to predict. Yet almost everything about trading and markets has calendar structure baked in: turn-of-month flows, day-of-week effects in volume, the pre-holiday drift in liquidity, the last-half-hour scramble before the close. That structure only becomes usable once it's unpacked into explicit, separate features.

The idea: decompose the timestamp into its calendar parts

Rather than feeding a raw timestamp to a model, extract the individual calendar attributes that might carry signal: day of week, day of month, month of year, quarter, whether the date is a holiday or the day before/after one, and — for intraday data — minutes since market open or minutes until close. Each becomes its own feature, typically a small integer or a categorical to be encoded, and the model is left to discover which of these actually correlate with the target rather than being handed one meaningless big number.

$$\text{minutes\_to\_close} = t_{\text{close}} - t$$

In plain English: for an intraday bar at time $t$, compute how many minutes remain until the market closes at $t_{\text{close}}$ — a feature that captures the well-documented tendency for volume, spread, and volatility to behave differently in the final minutes of trading, something the raw clock time alone wouldn't reveal without the subtraction.

Worked example: building four features from one timestamp

Take the timestamp 2026-07-24 15:52:00 for a market that closes at 16:00. Extracting calendar parts: day of week = Friday, day of month = 24, month = July, and minutes to close = $16{:}00 - 15{:}52 = 8$ minutes. A model trained on volume data might learn that Fridays late in the day and the final 15 minutes before close both see volume spikes — but only because those four numbers were handed to it explicitly as separate columns rather than buried inside one opaque timestamp value.

What this means in practice

Calendar features are cheap to compute and often surprisingly predictive in market microstructure and flow-driven models — end-of-quarter rebalancing, options expiry Fridays, and the open/close volume smile are all calendar effects hiding in plain sight. The catch is that raw day-of-week or month-of-year integers imply a false ordering (December, month 12, isn't "more" than January, month 1, in any useful sense, and Sunday wrapping back to Monday isn't captured by treating day-of-week as 0 through 6 on a straight line) — a limitation usually fixed by encoding these as categoricals or with the cyclical sine/cosine transform rather than feeding the raw integer to a model that assumes ordinary numeric distance.