ClarqClarq
← All posts

Why "This Week" Means Something Different to Every Team Member

Clarq Team
Why "This Week" Means Something Different to Every Team Member

You'd think "this week" is a simple concept. It isn't.If your agency has a developer in Lisbon and a project manager in New York, you have a problem most teams don't notice until billing disputes start.

The Friday night surprise

It's 11 PM Friday in Lisbon. Your developer wraps up a two-hour sprint and logs the time. Locally, it's Friday, and it is. But in New York, where your client contract defines the billing week, it's still Friday afternoon. No issue this time.Now shift that to Monday. It's 3 AM Monday in Lisbon. That's still Sunday evening in New York. Your developer's Monday entry lands in last week's report. The PM pulls the numbers on Friday, the totals don't match the invoice, and everyone spends 30 minutes on Slack doing timezone math instead of real work.

Where it actually breaks

Week boundaries shift. Lisbon's Monday starts 5 hours before New York's. Entries near midnight create ghost hours that land in the wrong week depending on who's looking.Reports disagree. A manager in New York and a team lead in Porto pull the same weekly report. Different totals, because their "week" is anchored to different clocks.Approvals derail. A timesheet submitted as "done" on Friday in Lisbon still shows incomplete Thursday in New York. The approver rejects it. Confusion ensues.Billing misaligns. Hours slip between periods. A retainer client paying for 40 hours/week gets billed 38 one week and 42 the next, not because the work varied, but because the math did.

The fix: one timezone for all business logic

Pick one timezone, your organization's business timezone, and make every date calculation use it. Not the user's local clock. Not UTC. The timezone your contracts, invoices, and clients operate in.Week boundaries become absolute. Monday 00:00 in your org timezone is Monday for everyone. Your developer in Lisbon sees the same "Monday" as your PM in New York.Reports become deterministic. Same query, same numbers, every time, regardless of who's running it.Approvals make sense. "Submitted on Friday" means the same Friday for the whole team.

Practical steps

  1. Store a timezone on your organization, not your users. One America/New_York field that governs all date math. Users can see their local clock, but business logic uses the org timezone.
  2. Convert at the calculation layer. Don't just format dates for display. Convert timestamps to the org timezone before determining which week or period they belong to.
  3. Query wider, filter tighter. When pulling entries for "Tuesday," query ±1 day in UTC, then filter in application code after converting. This kills the off-by-one bugs that timezone-naive queries create.
  4. Test the boundary. Create entries at 11 PM Lisbon time and check they land in the correct New York week. If that holds, you're solid.

This isn't just a time tracking problem

The pattern applies anywhere dates drive business logic: reporting periods, SLA calculations, deadline enforcement, scheduling. Anywhere "EOD Friday" needs to mean one specific moment for the whole team.The fix is boring. One config field, consistent date math. But the payoff is that your numbers just work, for everyone, every time.

At Clarq, we built organization-timezone-aware calculations into every layer, from weekly views to approvals to reporting. If your agency is dealing with timezone headaches, we'd love to help.