A 100 USD counter example: the challenge reset moves by one UTC hour

25 October 2026. A hardcoded 22:00 UTC reset could erase a hypothetical 100 USD daily loss from your counter one hour early tonight. The loss has not disappeared from the challenge rule. Your software has started the next day too soon.

I ran eight offline checks of saved clock readings and their expected dates to pin down that boundary. All eight passed. This is a clock check, not a test of an account, a trading strategy or a complete loss guard.

Start with the written reset rule

The question is simple: how is the daily loss limit calculated? The FTMO Academy lesson discusses that question. The current trading objectives specify a recalculation at midnight, 00:00 CE(S)T. Check the rule for your exact product before applying this example. This article does not assume a loss percentage shared by every challenge.

CE(S)T means Central European time, including its summer-time 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 does not.

The important date is the local rule date. It is not necessarily the date printed by a broker server, your laptop or an unlabelled UTC log.

The disputed half hour

At 22:30 UTC on 25 October, the Prague clock reads 23:30 with an offset of plus one hour. That is still 25 October. A program that changes its daily counter at 22:00 UTC has already advanced to 26 October, thirty minutes before the correct local boundary.

In the hypothetical 100 USD example, that program would display a fresh daily counter while the written rule still belongs to the old day. The example illustrates a date mismatch. It does not calculate remaining permitted loss, which also needs the exact equity, open positions, fees and product rules.

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 evidence has seven timestamp rows plus one assertion for the elapsed time between those local midnights. That local day lasts 25 hours. The eight passing assertions establish these mappings only. They do not establish breach detection, broker-server mapping, live execution or profitability.

Why a 24-hour timer gives the wrong answer

A plausible shortcut is to save yesterday's reset and add 24 hours. Another is to hardcode 22:00 UTC because that matched the previous summer midnight. Both hide the same assumption: that the UTC interval between local midnights never changes.

On this date, it changes. The next Prague midnight is 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 relying on it

1. Find the timezone and reset wording for your exact challenge product.
2. Convert the next local midnight to UTC with a timezone database that includes daylight-saving rules.
3. Compare that instant with the firm's dashboard countdown. If they disagree, resolve the rule or timestamp source before trusting the local counter.
4. Test an instant just before the boundary and one exactly on it. The first must retain the old local date; the second must begin the new one.

For this example, 25 October at 22:59:59 UTC is still the old rule day. At 23:00:00 UTC, the Prague date changes to 26 October. Keeping that one-second boundary in a repeatable clock check is more useful than judging a clock from its display alone.

Your self-check is the next reset instant and the dashboard countdown. The optional free Pre-Check can help organise the written rules. The clock check remains one small part of that review.