Whose midnight the account runs on

Three zones are in play at once. The operator keeps one, usually UTC; your device displays another; and the stored record is written in a third or in the operator's. The only one that decides anything is the operator's, and the only one you can see is your own.

Open the partner account Read the time clauses

Account spec

Usually stored in: UTC
Offset for a sample reader: UTC+13
Daylight saving effect: 24 h day reads as 25 h or 23 h
Pages stating a zone: 9 of 40

the boundaryThe instant the account's day is measured from. On the samples it is 00:00 UTC, which is a different wall-clock moment for every reader.

the countdownWhat a window is measured from and whether day one counts. A window advertised as 30 days delivers 29 days 23 hours 59 minutes on the sample.

the calendarThe working-day clock money moves on, with its cut-off, its weekends and its holidays. One working day covered 87 hours 30 minutes on the sample.

Direct answerThe operator keeps one zone, normally UTC, and every allowance, window and record is measured on it. Your device displays another. A daylight-saving change moves your displayed clock by an hour without moving the accounted instant, so across the change night one account day measures 25 hours of wall time and another measures 23.

The three zones

the stored zone: The zone a timestamp is written in. On sample G, none of 40 invented terms pages states which one this is, which is why a dispute over a refusal, a settlement or a claim so often turns on a number the player cannot check.
the operator's zone: The zone the rules are applied in: the day an allowance resets on, the day a window opens on, the hour a cut-off falls at. Usually UTC, sometimes the operator's own legal seat.
your zone: The zone your device displays. It is the least authoritative of the three and the only one you can read directly.

Converting a stated instant into your own clockstored instant 2026-03-07 15:00:00 UTC your offset UTC+13 your local time 15:00 + 13 h = 04:00 on 8 March your local date 8 March, a day later than the stored date the same conversion the other way, from a rule stated locally rule "resets at midnight" your offset UTC+13 stored instant 00:00 - 13 h = 11:00 UTC on the previous day so the operator sees the reset at 11:00 and writes that date

The hour that moves

Daylight saving is the part of the clock that most often goes unmentioned and is the easiest to demonstrate. Sample H takes a daily allowance fixed at 00:00 UTC and a reader whose own zone switches from UTC+0 to UTC+1 on the last Sunday in March, which is when several northern-hemisphere zones make the change.

Sample H - a 24-hour day that reads as 25 hoursallowance resets at 00:00 UTC, every day reader's offset, winter UTC+0, so the reset reads 00:00 local reader's offset, summer UTC+1, so the reset reads 01:00 local change moment 01:00 UTC on the last Sunday in March the reader's clock jumps 01:00 -> 02:00 local Saturday reset (winter) 00:00 UTC = 00:00 local Sunday reset (summer) 00:00 UTC = 01:00 local elapsed time between them 24 h 00 m of real time wall clock reads on Sunday 01:00 so the reader's wall clock counts 25 hours between two resets in the autumn the arithmetic reverses elapsed time between them 24 h 00 m wall clock counts 23 hours a 24-hour time-out set on the Saturday and lifted on the Sunday costs 25 wall-clock hours, not 24

The elapsed time is 24 hours in both directions, because the operator's clock did not move. The reader's clock did. So the same sentence, "a day", describes two different numbers of hours on your wall twice a year, and neither of them is the number the terms imply.

How the sampled pages state a zone

9 of 40state a zone anywhere in the terms

4 of 40name UTC specifically

0 of 40state how daylight saving is handled

31 of 40leave the zone to be inferred

Before acting on a deadline, convert it to your own clock and write down the resulting local date and time. A deadline you have not converted is a deadline you have not read.
Do not use your device's clock as the authority for a cut-off. It is a display, and on the sample a 3.2-second error decided a bet.
If the terms name no zone, look for the zone in the record instead: a transaction shows the operator's timestamp, and that is the clock the rules are applied on.
If the terms name daylight saving nowhere, do not assume it is handled. On the sample, none of 40 pages does.
Treat the account day and the local day as two different objects. They share a name and not a boundary.

Which day the account keepsthe operator day vs your day The time written on a betwhat the stored time shows The calendar money moves onworking days and holidays Every figure in one placewith the arithmetic behind it