Mailbox troubleshooting · Practical guide

Mailbox timezone selection: identify which clock controls the campaign

Do not assume a mailbox has one timezone setting that controls every send rule. In Zintara, campaign windows and workspace budgets have their own time context, while mailbox daily counters use the database's date boundary.

Reviewed · Examples are illustrative

Who this helps: Mailbox owners planning time boundaries, capacity, access and reply coverage.

Define the decision

The current mailbox update fields do not include an independent mailbox timezone. Campaign scheduling uses its configured timezone, and workspace and campaign budget calculations use their respective timezones. Mailbox counters are based on CURRENT_DATE in the database session, so verify that deployment setting when diagnosing a reset boundary.

Work through the procedure

  1. Identify whether the question concerns an allowed send window, a campaign budget, a workspace budget or a mailbox counter.
  2. Record the timezone used by that specific control.
  3. Translate one relevant timestamp into the campaign and operator's local time.
  4. Verify a controlled boundary case before changing configuration or interpreting a reset.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Time review
Campaign window: configured campaign timezone
Workspace daily budget: workspace timezone
Mailbox sent-today counter: database CURRENT_DATE boundary
Operator display: may be local time
Diagnostic task: identify which gate is blocking the send before changing the campaign window.

Read the result

The worksheet explains why two daily figures can reset at different apparent local times without proving a defect. It also prevents changing the wrong setting. A timezone change should be reviewed against pending work and allowed windows, not treated as a shortcut to bypass an exhausted budget.

Check before moving on

  1. Use named timezones for campaign scheduling rather than a permanent fixed-offset assumption.
  2. Ask the operator to verify database timezone without exposing secrets.
  3. Recheck dates around daylight-saving transitions where relevant.

Limits and next action

These statements were checked against current campaign, budget and mailbox code. They do not establish the actual database timezone of every deployment. Zintara does not expose a universal mailbox-timezone control through the current mailbox patch fields.

Source: Zintara product context; procedures and examples are editorial guidance

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features. Check current provider guidance before changing mailbox configuration.

Related guides

Explore the Zintara workflow