Working-hours overlap between China and the UK

China is UTC+8 and does not observe daylight saving, so the overlap with a UK working day changes twice a year without anyone in China moving. These are the actual numbers, calculated rather than estimated, for the shift patterns worth considering.

The measured overlap

Hours in common with a local 09:00–17:00 day. China keeps one time zone all year at UTC+8; the UK moves between GMT and BST, which is why each figure is a pair.

Engineer's hours (China) Seen from the UK Overlap, summer Overlap, winter
09:00–18:00 (standard) 02:00–11:00 2 hours 1 hour
12:00–21:00 (shifted) 05:00–14:00 5 hours 4 hours
14:00–23:00 (late) 07:00–16:00 7 hours 6 hours

The middle row is the one that matters. A midday start in China gives four to five hours of genuine overlap with a London day — enough for a standup, a review, a design conversation and an unplanned problem, which is to say enough to work normally. It is also a humane schedule: finishing at 21:00 is a real imposition but a sustainable one, which the 14:00–23:00 row is not, however good its overlap number looks.

A standard Chinese day, by contrast, leaves you one hour in January. That is not a working relationship; it is a daily handover with a meeting attached.

What the seasonal swing actually does

Because China does not shift and the UK does, your overlap quietly shrinks by an hour every autumn and returns every spring. Nobody announces it and no calendar flags it — the team simply finds late October harder than early October and usually blames something else.

It is worth naming in advance. If four hours in summer is comfortable and you have no slack, three in winter will not be, and the fix — moving the engineer's start an hour earlier for the winter months — is trivial if agreed up front and awkward if raised as a complaint in November.

Designing for the hours you do not share

Even the best pattern here leaves most of the day unshared, so the overlap is a resource to spend rather than a working day to fill. What works:

  • Put decisions in the overlap and work outside it. The shared hours should carry the things that genuinely need both parties — review, design disagreements, anything ambiguous. Implementation does not need an audience.
  • Make the work unblockable. The expensive failure is not slower communication, it is an engineer stopping for fourteen hours because a question has nowhere to go. Tickets with enough context to start, access granted before it is needed, and an explicit rule about what to do when blocked — attempt the next thing, write the question down — recovers more time than any tooling.
  • Write things down, and mean it. A team that decides things in conversation will re-decide them constantly. This is the discipline distributed teams find hardest and benefit from most, and a China-based colleague makes the cost of not doing it immediately visible.
  • Review asynchronously, properly. A pull request that sits for a day because the reviewer is asleep costs a day. Two reviewers in different zones, or an agreement that review happens first thing, removes most of it.
  • Rotate the inconvenience. If every call lands at 21:00 for one person and 14:00 for everyone else, that asymmetry is a resignation letter being written slowly. Occasionally moving the meeting the other way costs the UK team little and signals a great deal.

Public holidays, which catch everybody out

Chinese public holidays do not line up with British ones, and two of them are long: Chinese New Year (late January or February, dates moving each year with the lunar calendar) and the National Day holiday in early October. Both can mean a week or more away, and Chinese New Year in particular is the one time of year when travel and family obligations are close to non-negotiable.

None of that is a problem if it is in the plan. It is a problem if you discover it the week you were going to ship. Ask for the year's dates at the start of the engagement and put them in the same calendar as everyone else's leave.

Worth noting that the shift pattern is a contractual matter, not a preference you can revisit informally later. Whichever engagement model you choose, agree the hours in writing at the start — a contractor asked to move from a 09:00 start to a 12:00 start six weeks in is being asked to accept a materially different job.

If your team is in the US

The arithmetic is less kind and worth knowing before you plan around it. A China working day sits almost entirely outside a US one — the standard 09:00–18:00 in China is 21:00–06:00 on the US east coast — so an American team is running an async-first relationship rather than a shifted-hours one, and the practices above stop being good hygiene and become the whole operating model.

We would rather say that plainly than let you find out in week three. If continuous overlap is genuinely a requirement for your team, tell us on the first call and we will say whether we think this fits.

The hours are also the one constraint no commercial arrangement can soften. Payment, contracting and IP all have good answers — see paying an engineer in China and the engagement model — but nothing moves China out of UTC+8, so this is the question to settle honestly before the others.


This is one of 6 guides supporting our main page on hiring remote Chinese AI engineers, which covers rates, the engagement model and how a placement actually starts.

Also worth reading

Thinking about a role?

Tell us what you are building and the constraints you are working under. If we are not the right route for it, we will say so rather than sell you one.

Start a conversation