You’ve found a clean result: your crypto strategy earns most of its return between 13:00 and 14:00 UTC. You’ve checked the fees, rerun the backtest and paper-traded the signal. Now you’re preparing a US equities version, and the strongest hour appears to be 09:30–10:30 New York time.
Before you trust either result, check what the clock did. US daylight saving time shifts the New York open by an hour relative to UTC. If your features, session labels and orders use different notions of time, the strategy may be exploiting a calendar boundary rather than a repeatable market pattern.
You don’t need to throw away time-of-day research. You need to define which clock your hypothesis is about, then make every part of the backtest use it consistently.
First, say what the hour means
“The first hour” sounds precise until you name the reference clock. It could mean the first 60 minutes after the NYSE opens, 09:30–10:30 in New York civil time, or a fixed UTC interval. Those definitions agree for part of the year and diverge around daylight saving changes.
For the equity hypothesis, use exchange-local session time: 09:30 New York time means 09:30 whether New York is on EST or EDT. For the crypto hypothesis, a fixed UTC hour may be the intended variable. Crypto trades around the clock, so there’s no venue opening bell to anchor the claim.
Write the definition down before tuning. “Trade the first hour after the regular-session open” is testable. “Trade the hour where the signal works best” invites the optimizer to choose a clock convention along with the strategy.
Where clock mismatches sneak in
Suppose your equities data is stored in UTC, your feature code groups rows by their UTC hour, and your execution rules open positions at 09:30 New York time. After a daylight saving shift, the market open moves from 14:30 UTC to 13:30 UTC. A feature labelled “first hour” by its UTC bucket now refers to a different slice of the session.
A similar trap appears when you build bars from timestamps. If you resample in UTC and then convert labels to New York time, you can get unexpected boundaries, especially around the spring transition, when one local hour doesn’t exist, and the autumn transition, when one local hour occurs twice. A timestamp such as 01:30 local time is ambiguous on that autumn Sunday unless it carries a UTC offset or is represented in UTC.
For your crypto result, the calendar can still matter. A UTC-hour strategy may line up with US market activity for months, then appear to shift when US clocks change. That doesn’t make the strategy invalid; it changes what you can claim. You may have measured a fixed UTC pattern that sometimes overlaps the US open, rather than an effect tied to that open.
Build the session clock into the test
Keep event timestamps in UTC as the canonical record. Derive local session fields from a named time zone such as America/New_York, using a time-zone database that handles historical rule changes. Don’t hard-code “UTC minus five” or “UTC minus four”: neither offset defines New York time year-round.
| Decision | Equities example | Crypto example |
|---|---|---|
| Hypothesis clock | Minutes since regular-session open | UTC hour of day |
| Session source | Exchange calendar, including holidays and early closes | Continuous UTC calendar |
| Order timing | Next executable event after the signal | Next executable event after the signal |
Then test the boundary weeks separately. Compare performance before and after each daylight saving change, and inspect whether the winning interval stays attached to the market session or stays fixed in UTC. If you’ve searched many hours, dates and offsets for the best result, include that search in your overfitting accounting; the clock choice was another trial.
A time zone is a rule set, not a number of hours to subtract. Store UTC events; derive local market time when you need it.
What your paper run should confirm
When you move the strategy to paper, log both the event’s UTC timestamp and its session-relative minute. That gives you a quick way to catch a strategy that thinks the open is at 09:30 but is actually firing at 10:30 local time. Check holidays and early closes too; a normal-session schedule copied across every weekday will happily invent trades on days the exchange is closed.
And when the clocks change, resist the urge to “fix” a result by shifting the signal until the equity curve looks familiar. First verify the stated hypothesis, the calendar and the order timing. If the result moves with the market session, you’ve learned something about session behavior. If it stays on the same UTC hour, you’ve learned something else. Your backtest should preserve that distinction.
← All posts
