On 25 October, a hardcoded 22:00 UTC reset could have erased a hypothetical 100 USD daily loss from your counter one hour early. That code would have started the next rule day one hour early on 25 October 2026.
Eight original offline clock checks from 25 October 2026 passed. This is a clock check about rule dates.
Start with the written reset rule
The question is simple. How is the limit calculated? The FTMO Academy lesson discusses that question. The current trading objectives describe a recalculation at midnight, 00:00 CE(S)T. CE(S)T means Central European time with its summer change. I use the IANA timezone Europe/Prague for the mappings below. A named timezone carries the change between UTC plus two hours in summer and UTC plus one hour in winter. A fixed offset misses that change.
The local rule date matters. It is not always the date on a broker server, your laptop or an unlabelled UTC log.
Many counters rest on one idea. A daily reset always happens at the same UTC hour. On 25 October the same local midnight maps to a different UTC hour. That shift is the point of this example.
The disputed half hour
At 22:30 UTC on 25 October 2026, the Prague clock read 23:30 with an offset of plus one hour. That was still 25 October. A program that changed its daily counter at 22:00 UTC had already moved to 26 October 2026. It was thirty minutes before the correct local boundary.
In the hypothetical 100 USD example, that program would show a fresh daily counter while the written rule still belonged to the old day. The loss stayed live under the challenge rule. The program had started the next day too soon.
These are three of the saved timestamp cases.
- 24 October, 22:00 UTC becomes 25 October, 00:00 at UTC+02.
- 25 October, 22:30 UTC becomes 25 October, 23:30 at UTC+01.
- 25 October, 23:00 UTC becomes 26 October, 00:00 at UTC+01.
The saved set holds seven timestamp cases plus one check for the elapsed time between those local midnights. That local day lasted 25 hours.
Why a 24-hour timer gives the wrong answer
A common shortcut is to save the prior reset and add 24 hours. Another is to hardcode 22:00 UTC because that matched the prior summer midnight. Both hide the same idea. They assume the UTC span between local midnights never changes.
On 25 October 2026 it changed. The next Prague midnight was at 23:00 UTC. I would calculate the next midnight in the written rule timezone first, then convert that instant to UTC for storage and comparison. I would not silently rename an uncertain server timestamp as UTC.
Check your counter before you rely on it
Use these four steps. They take about five minutes.
- Find the timezone and reset wording for your exact challenge product.
- Convert the next local midnight to UTC with a timezone database that includes daylight saving rules.
- Compare that instant with the firm's dashboard countdown. If they disagree, fix the rule or timestamp source before you trust the local counter.
- Test one instant just before the boundary and one exactly on it. The first must keep the old local date. The second must start the new one.
For this example, 25 October 2026 at 22:59:59 UTC was still the old rule day. At 23:00:00 UTC, the Prague date changed to 26 October 2026. That one-second boundary in a repeatable clock check tells you more than a glance at a clock face.
Your own check is the next reset instant and the dashboard countdown. The optional free Pre-Check, the free Prop Rule Guard, can help organise the written rules.
What this check does not show
This clock check from 25 October 2026 shows these mappings only. It does not show breach detection, broker server mapping, live fills or profit. It does not set a loss percent shared by every challenge. It does not show remaining loss allowance under a limit, which also needs exact equity, the account value including open trades, plus open positions, fees and product rules. Check the rule text for your exact product.
Top comments (0)