US–Philippines Working Hours: Design an Engineering Overlap Schedule

Hiring a Philippine developer for a US team does not require everyone to share the same working day. It does require a specific agreement about when people can make decisions together, what happens between those windows and whether the proposed hours are sustainable for the engineer.

Start with the work that needs live collaboration. Then choose a schedule using named time zones, check it in both US seasons and discuss it before making an offer. “US overlap” is too vague to put in a role brief.

This guide provides two fictional schedules and a working-hours agreement you can adapt. The examples are planning tools, not promises about a candidate's availability or Arca's service terms.

Decide what actually needs a shared hour

A product discussion, a difficult debugging session and a routine status update make different demands on a calendar. Before choosing hours, list the decisions that would otherwise stall until the next working day.

Work	Proposed collaboration approach	Person who must be available
Clarify an ambiguous feature	A prepared live discussion during agreed overlap	Product decision-maker and engineer
Review an ordinary change	Written pull request and a stated review window	Named technical reviewer
Resolve a design disagreement	Write the options first; use a live conversation if needed	Technical decision-maker and affected engineers
Report progress or a nonurgent blocker	A written update with context and next action	Owner who can respond during their next working period
Respond to a production incident	A separately agreed incident and coverage arrangement	Explicitly assigned responder and escalation owner

This is an example division, not a universal rule. A developer exploring unfamiliar requirements may need more live access to teammates than one implementing well-defined work. Review that need as the assignment changes.

Choose an initial window around those decisions rather than copying an arbitrary number of overlap hours. GitLab's own communication handbook describes using asynchronous communication as a starting point and recording conclusions reached offline. That is a useful operating example, not evidence that every engineering team should follow the same schedule.

Calculate the actual US–Philippines time difference

Use America/New_York, America/Los_Angeles and Asia/Manila when setting up the examples below. A city-based zone includes rules that a fixed UTC offset cannot capture. The W3C's technical note on working with time zones explains why that distinction matters for recurring meetings.

Under the rules checked for these examples, Manila is UTC+8 throughout the year. New York is UTC−5 in standard time and UTC−4 in daylight time; Los Angeles is UTC−8 and UTC−7 respectively. The IANA time-zone database maintains location-specific time rules; its Asia data contains the Manila entry.

That makes Manila 13 hours ahead of New York in standard time and 12 hours ahead in daylight time. It is 16 hours ahead of Los Angeles in standard time and 15 hours ahead in daylight time. These examples do not describe every US location. Some places follow different daylight-saving rules.

Two schedules to discuss with candidates

The following examples preserve a two-hour US morning window. They show only shared collaboration hours, not the engineer's full shift, breaks or total working time. Availability and the surrounding workday would need separate agreement.

Example A: A New York product team

A fictional New York team wants its product lead and Philippine engineer available together from 08:00 to 10:00 New York time. It proposes using that window for questions and review discussions, while writing routine updates beforehand.

Example date	New York collaboration window	Equivalent Manila window
20 January 2026, standard time	08:00–10:00, America/New_York	21:00–23:00 on 20 January, Asia/Manila
20 July 2026, daylight time	08:00–10:00, America/New_York	20:00–22:00 on 20 July, Asia/Manila

The Philippine evening becomes an hour later when New York returns to standard time. Ask about both versions. A candidate agreeing to a July schedule has not necessarily agreed to its winter equivalent.

If the later window does not work, the team can examine an earlier US start, fewer recurring live sessions or a different allocation of work. None of those changes should happen by assumption after the hire.

Example B: A Los Angeles engineering team

A fictional Los Angeles team proposes 08:00–10:00 in its own time zone. The same local US hours create a later Philippine window and cross a date boundary.

Example date	Los Angeles collaboration window	Equivalent Manila window
20 January 2026, standard time	08:00–10:00, America/Los_Angeles	00:00–02:00 on 21 January, Asia/Manila
20 July 2026, daylight time	08:00–10:00, America/Los_Angeles	23:00 on 20 July–01:00 on 21 July, Asia/Manila

This team has a different hiring constraint from the New York team, despite both requesting “two hours of US overlap.” It should discuss the late-night requirement openly and check whether its engineer and reviewer can sustain it.

For a Monday–Friday US arrangement, the date crossing can also put the final shared window on Saturday morning in Manila. Put actual dates into the calendar before agreeing a weekly pattern. A timezone conversion alone does not establish appropriate working conditions.

Choose which local clock the agreement follows

There are two different decisions hiding inside a recurring meeting invitation:

• Keep the US local window fixed. The equivalent Philippine hours move when the US clock changes, as in the tables above.
• Keep the Philippine local window fixed. The US participants' meeting time moves instead.

Write down the chosen approach. A calendar can convert a meeting correctly and still surprise somebody whose availability was agreed under a different assumption.

NIST's current daylight-saving guidance lists the US change dates and the locations that do not observe the general rule. Recheck the actual zones before each seasonal transition and after a teammate relocates; time-zone rules can change.

Use a short working-hours agreement

Copy these prompts into the role brief and confirm them with the people involved:

1. People and zones: Which engineer, reviewer and product owner need to collaborate? Record each person's named time zone.
2. Shared window: What are the start, end, days and local dates on both sides? Which local clock stays fixed across seasonal changes?
3. Purpose: Which decisions belong in the window? Which updates should arrive beforehand?
4. Responses: When should nonurgent questions receive attention during agreed working periods? Who covers a reviewer being unavailable?
5. Boundaries: What happens outside agreed hours? Keep incident coverage, extra availability and planned absences explicit.
6. Review: Who checks the arrangement after the first weeks and before seasonal changes?

This worksheet proposes operational questions. Resolve working-time, holiday and engagement obligations through the appropriate people and advisers; a shared calendar is not an employment agreement.

Make the handoff useful enough to act on

In either fictional team, the engineer can finish their working period with a short record: the change attempted, a link to the work, checks completed, the unresolved decision and the person who can resolve it. The reviewer leaves a decision with enough context for the engineer to continue later. If work needs a permission change, route that to the access owner; someone being online does not give them authority to approve it.

“Blocked on the API” is difficult to use. “The account endpoint rejects the new optional field; I need the API owner to confirm whether this release should accept it” gives the next person a decision to make. Keep sensitive information in approved systems and give documents an owner so instructions stay current.

During the first month, use the first small assignment to check whether this handoff actually reaches the right reviewer. If work repeatedly waits on the same unavailable decision-maker, changing the engineer's shift may leave the real constraint untouched. Adjust the review responsibility or the task definition before extending someone's day.

Bring your actual working window to Arca

Arca matches Philippine software engineers to a team's role, stack, seniority and working needs. Tell us which US city your team works from, the decisions requiring live discussion and the support available outside shared hours. We can discuss those requirements in the search; location alone does not guarantee a shift.

If you are still defining the role and hiring arrangement, start with our guide to finding and hiring offshore developers. Bring the completed working-hours prompts to a conversation with Arca so the schedule can be evaluated alongside the engineering work.