The most wasted column in business data
Almost every business record has a timestamp, and it is frequently handed to a model as a raw number. In that form it encodes a trend and little else.
Business activity is driven by calendar structure: weekly rhythms, month-end, pay dates, holidays, school terms. All of that is recoverable from a timestamp, and none of it is visible in the raw value.
What is usually worth extracting
- Day of week - almost always significant in any business with customers
- Position in month - first working day, month-end, and the gap between them
- Week of year - seasonality, though beware year boundaries
- Hour of day - for anything with an intraday pattern
- Working day or not - including the local holiday calendar
- Days until or since a holiday - often stronger than a simple flag
- Elapsed time since a previous event - days since last order is frequently the single most predictive feature available
That last one deserves emphasis. In customer models, recency does a great deal of work and it is derived rather than stored.
Cyclical encoding
Day 31 and day 1 are adjacent in reality and maximally distant as numbers. December and January are neighbours; as month numbers 12 and 1 they are far apart.
Encoding cyclical values as a pair of sine and cosine components preserves the wraparound so the model sees the end of the cycle as close to its beginning. It is a small change that removes a genuine class of error, particularly around year end.
Tree-based models are less sensitive to this than linear ones, but it still helps, and it costs nothing to include.
Holidays are harder than they look
A single is_holiday flag misses most of the effect. Retail demand shifts in the days before a holiday and slumps after; some holidays move each year; regional holidays differ within one country.
| Feature | Why it matters |
|---|---|
| Days until next holiday | Captures the build-up, not just the day |
| Days since last holiday | Captures the slump afterwards |
| Holiday type | A bank holiday and a religious festival differ |
| Regional applicability | Scotland and England do not share every date |
| Shifted trading days | A closed Monday moves demand to Saturday |
Easter alone causes considerable trouble because it moves by several weeks between years, so anything keyed to week number mis-aligns.
Time zones and the traps that follow
Store timestamps in UTC and convert for feature extraction, not the other way round. Extracting hour of day from a UTC timestamp for a business operating across time zones produces a nonsensical daily pattern.
Daylight saving introduces two further oddities each year: a day with 23 hours and one with 25. If you aggregate by day and compare year on year, those two days will look anomalous for reasons nothing to do with your business.
A timestamp handed over raw is a rich field reduced to a counter.