15 September 2026
One of PixelTrader's hard limits is a day-loss stop: a broker down 30% on the day gets halted. "On the day" means measured against a baseline captured when the trading day starts, so the baseline has to be re-set every morning.
In live modes that is easy. The market closes, the market opens, and the open is the signal to re-baseline every broker.
Simulation replays a historical window instead, and its clock is simulated. It never passes through a real market close, because no time is actually passing. So the new-day trigger had to come from the replay clock crossing a date boundary.
The clock crossed the boundary and announced it correctly. The floor printed a new trading day. And then the function that actually re-baselines the brokers compared against today's real date — the wall-clock date on the machine — decided nothing had changed, and did nothing.
The result is a rail that appears to work and does not. Over a multi-day replay the day-loss stop was measuring each broker against a baseline from whenever the session had started, which could be forty simulated days earlier. A broker could be down 30% on the simulated day and never trip it.
This is the failure mode I care most about. A safety limit that is absent is obvious. A safety limit that is present, visible in the UI, documented on the website, and silently measuring the wrong thing is worse than one that was never built, because you stop checking.
The rebaseline asks the simulation for the current moment rather than asking the operating system. Same rail, same threshold, same code path in every mode — only the source of the date changed.
The wider principle it forced: once any part of the program can be in simulated time, nothing is allowed to read the real clock directly. Every "what time is it" goes through one function that answers honestly for whichever mode is running. Mixing the two is not a bug you fix once; it is a bug you keep re-introducing until the mixed version stops being reachable.