Time-zone overlap is a number, not a promise

Every nearshore vendor promises they'll work in your time zone. It's meaningless. A team in São Paulo and a team in San Francisco can both be fully staffed and still miss each other by hours if nobody does the arithmetic. So we did the arithmetic, and we print the result on every engineer's card.

The claim vs. the calculation

The vague version sounds reassuring and commits to nothing. The honest version is a single number: how many hours per day does this engineer's working window actually intersect yours?

That's it. If a São Paulo engineer works 9:00–18:00 and your New York team works 9:00–17:00, the real overlap is five hours — not great overlap, not we're basically aligned. Five.

How we compute it

We store every engineer's and every account's working hours plus their time zone, normalize both windows to UTC, and take the intersection. Simplified, it looks like this:

class OverlapCalculator
  def initialize(talent:, account:)
    @talent = talent
    @account = account
  end

  # Overlap in hours per day.
  def hours
    talent = utc_window(@talent.timezone, @talent.working_hours_start, @talent.working_hours_end)
    client = utc_window(@account.timezone, @account.business_hours_start, @account.business_hours_end)

    # Windows recur daily, so check the client window shifted by ±24h too
    # and keep the best intersection.
    [-24, 0, 24].map { |shift| intersection(talent, [client[0] + shift, client[1] + shift]) }.max
  end

  private

  def utc_window(zone, from, to)
    offset = ActiveSupport::TimeZone[zone].now.utc_offset / 3600.0
    [from - offset, to - offset]
  end

  def intersection(a, b)
    [0.0, [a[1], b[1]].min - [a[0], b[0]].max].max
  end
end

Two details matter here. We shift the window by ±24 hours before intersecting so a pairing that straddles the UTC day boundary still measures correctly. And we compute the offset with a live ActiveSupport::TimeZone lookup rather than a hard-coded number, so daylight saving time doesn't quietly turn a real six-hour overlap into a fiction.

If your vendor can't tell you the overlap in hours, they haven't measured it — they've hoped.

Why it's non-negotiable for us

A number changes the conversation. Instead of debating whether nearshore feels aligned, you look at a shortlist and see 8h, 6h, 4h and decide what your workflow actually needs:

• Heavy pairing / real-time review? You want 6+ hours.
• Mostly async with a daily standup? Four is plenty.
• On-call or incident response? Overlap becomes a hard requirement, not a nice-to-have.

Making it a figure also keeps us honest. We can't quietly place someone whose day barely touches yours, because the mismatch is sitting right there on the card next to their rate.

That's the theme in everything we build: turn the fuzzy promises of this industry into things you can actually check. Overlap was an easy one — it was always just a calculation nobody bothered to show you.