Put a Pacific-time agency's nine-to-five next to the nine-to-five of a developer in Lahore, Bengaluru or Manila and the number of shared working hours is zero. Not a few. Zero. Every subcontract conversation that says "we'll have good overlap" is quietly promising that somebody will move their day, and the useful question is who, by how much, and what happens twice a year when the clocks change.
This post does the arithmetic once, for the cities agencies most often ask about, so the overlap clause in your subcontract can name hours instead of a feeling. It is calculation, not research on how teams behave. For the behavioural side, see how to run a distributed team without giving everyone two workdays.
Where do these numbers come from?
Every local time below was computed from the IANA Time Zone Database, release 2026e, published on 29 September 2026 at iana.org. That is the dataset operating systems and phones use to decide what time it is in a given city. The US daylight saving rule is stated by the National Institute of Standards and Technology (NIST): daylight saving time "begins at 2:00 a.m. on the second Sunday of March" and "ends at 2:00 a.m. on the first Sunday of November." For 2026 that is 8 March to 1 November, and by the same rule 14 March 2027 for the next start.
Four of the offshore cities do not change their clocks at all in this window: Karachi and Lahore sit at UTC+5, Bengaluru at UTC+5:30, Manila at UTC+8, and Buenos Aires at UTC-3. Warsaw follows the European Union's schedule, which moves on different dates from the US. That mismatch is the interesting part.
What does a four-hour window look like in local time?
Take the window most agencies actually ask for: four live hours, with the agency's working morning on the US side. Pacific 8:00 to 12:00, or Eastern 9:00 to 13:00. Computed from the 2026e data, the offshore team's local clock reads:
| Offshore city | Pacific 8:00-12:00, July | Pacific 8:00-12:00, January | Eastern 9:00-13:00, July | Eastern 9:00-13:00, January |
|---|---|---|---|---|
| Lahore | 20:00-00:00 | 21:00-01:00 | 18:00-22:00 | 19:00-23:00 |
| Bengaluru | 20:30-00:30 | 21:30-01:30 | 18:30-22:30 | 19:30-23:30 |
| Manila | 23:00-03:00 | 00:00-04:00 | 21:00-01:00 | 22:00-02:00 |
| Warsaw | 17:00-21:00 | 17:00-21:00 | 15:00-19:00 | 15:00-19:00 |
| Buenos Aires | 12:00-16:00 | 13:00-17:00 | 10:00-14:00 | 11:00-15:00 |
Read it from the offshore engineer's chair. A Lahore developer serving a Pacific agency spends a four-hour overlap between 8pm and midnight in July. A Manila developer is awake until 3am. For Eastern, the same Lahore developer is live from 6pm to 10pm, which is a late shift but a survivable one. Warsaw and Buenos Aires barely have a problem: a Warsaw team covering Pacific mornings is online until 9pm, and Buenos Aires is simply in the middle of its working day.
So there is no neutral answer. Somebody works an evening. The question is whether that evening is built into the person's schedule, with a late start, or is stacked on top of a normal day.
Which side pays, and does the contract say so?
Picture a 14-person Pacific agency that signs a subcontract with a two-person bench in Lahore, with "four hours of daily overlap" written into the agreement. Nothing in that sentence says which hours or whose clock. If the agency means 8:00 to 12:00 Pacific, the Lahore engineers are working until midnight. If the agency means 12:00 to 16:00 Pacific, the window runs 0:00 to 4:00 in Lahore and the clause is unworkable. Both readings satisfy "four hours."
The honest version of the clause names a clock and a number: the window runs 8:00 to 12:00 America/Los_Angeles, Monday to Friday, and the sub's working day is scheduled around it (for example, starting at 16:00 Lahore time). That sentence also tells the sub what rate to quote, because a 4pm-to-midnight shift is a different job from a 9-to-5.
My opinion, and one I would defend on a call: for work that is mostly code review, ticket grooming and written specs, a South Asian bench on a Pacific clock is workable with a shifted shift. For work that wants someone beside you for most of the day, such as pairing with a designer or untangling a client's legacy system live, it is the wrong geography, and you should say so before the pilot starts rather than after.
What happens when the clocks change?
Two things shift twice a year, and only one is obvious. The obvious one: the US moves, South Asia and the Philippines do not, so a window pinned to Pacific hours lands one hour later on the offshore clock after 1 November. The Lahore evening in the table above slides from 8pm-to-midnight to 9pm-to-1am without anyone changing the contract. The engineer absorbs an extra hour of lateness and nobody asked them.
The less obvious one is Warsaw. The EU moves on different dates from the US: on 25 October 2026 and again on 28 March 2027, according to the 2026e rules. From 25 October to 31 October 2026, and from 14 March to 27 March 2027, the US and Poland are on different offsets. In those weeks the Warsaw-to-Eastern gap is five hours instead of six, and a Pacific 8:00-12:00 window reads 16:00-20:00 in Warsaw, not 17:00-21:00. It is about three weeks a year in total. It is also exactly when a recurring standup invite, created in one person's calendar in one zone, shows up an hour wrong for half the team.
The fix is boring. Say in the contract which side's calendar governs. Put the recurring meetings in the US client's zone. And note the two mismatch weeks in the project plan so nobody schedules a go-live inside one.
What about the Friday cutover?
A Pacific Friday window of 8:00 to 12:00 in July is 23:00 Friday to 03:00 Saturday on a Manila clock, so the last hour of the week's live time falls on the engineer's Saturday. If your subcontract defines "business days" without naming a clock, a Friday release can become a Saturday obligation for the other party. Ask for the definition in writing before you promise a client a Friday cutover.
What should an agency owner do with this?
Before you quote work you cannot staff, run four checks:
- 1.Write the window as clock hours in a named time zone, not as a number of hours.
- 2.Decide which side's clock governs, and say so in the agreement.
- 3.Ask the sub what shift they will actually staff, and whether the people on it chose it.
- 4.Put the DST weeks on the project calendar.
If your clients need most of a working day in real time, a bench in a nearby zone is the honest answer, and no amount of process makes a Lahore evening match a San Francisco morning. If the work tolerates four live hours and the rest asynchronous, a shifted shift is a normal arrangement.
We work with agencies on exactly this question, and what an agency owner in this position wants is a clear line on who is online when, in writing. Our partners page describes how we work with agencies on overflow capacity, and if you have a quote you cannot staff at the margin the job needs, tell us the scope and we will say whether a subcontract pilot fits or whether a dedicated team of your own is the better answer. The margin side of the decision is in the economics of white-label development, and the questions to ask before the first pilot are in vetting a global development partner.
Sources
- IANA: Time Zone Database, release 2026e (published 29 September 2026; all local times above are computed from its rules)
- NIST: Daylight Saving Time (US start and end rule; 2026 dates 8 March to 1 November)