Time Zones and Office Hours in a Scheduled Job

The server runs on UTC. The clinic is in Lahore. The customer is in Miami. A job set to '9:00' will pick one of those clocks and ignore the other two. Someone gets a payment reminder in the middle of the night and mutes you. The message was correct. The hour was rude.

Store a time zone on the record that decides the send, define the hours you are willing to speak, and defer anything outside those hours to the next allowed slot. Do not drop it, and do not send it 'now' because the queue is impatient.

Put a time zone on the thing you are scheduling

A time zone belongs to the customer, the clinic, or the office that owns the relationship. Decide which, and store the region name, such as Asia/Karachi, not a fixed offset. Offsets change with daylight saving. A region name does not go stale in March.

If the zone is missing, do not guess from a phone number. Hold the item for a person or use the office default you wrote down. A guess that lands in the wrong country is worse than a morning delay.

Define hours as a window, not a single minute

Office hours might be 09:00 to 17:00 in that zone, excluding the days you do not work. A reminder that becomes due at 18:30 waits until 09:00 the next working day. Write whether weekends count. A gym and a clinic will answer that differently, and the job should not invent the answer.

One daily job at 09:00 local is easier to explain than a continuous sender that 'tries to be smart'. If you send continuously, you still need the window. Volume is not a reason to text at midnight.

• Region name stored, not only an offset
• A default when the zone is missing
• A window and the days you work
• Outside the window: defer to the next opening

Defer means the key still protects you

The deferred item must keep its idempotency key. When 09:00 comes, you send once. If the job runs twice at the open of business, the second run finds the key. Morning herds are when duplicates happen, because everyone retries at the same minute.

Show the planned local time in the log. 'Will send 2026-10-06 09:00 Asia/Karachi' is something the owner can check. 'Queued' is not.

A window check

zone = record.timezone or office default Asia/Karachi
local = now in zone
if local is a working day and 09:00 <= local < 17:00:
  send once for this key
else:
  schedule the next working 09:00 in that zone
  do not send now
log the zone and the planned local time

Test with a fixed clock. Do not test only on a Tuesday afternoon in your own city.

Test the awkward days

Test a due time just before the window, just after it, on a Friday night if you do not work Saturday, and on the morning daylight saving starts or ends if your customers live where that happens. Those four cases catch the bugs that a single happy-path test misses.

Ask one teammate in another city, or just change the zone on a test record to America/New_York and confirm the logged local time. If the log shows your server time with a different label, the conversion is wrong and you are about to learn that from a customer.

Apply it to one live case this week

Take one real item from the last month and walk it through Time Zones and Office Hours in a Scheduled Job. Write the input, the output a colleague could use without calling you, and the name of the person who may accept or reject the result. Keep these steps in view: Store a real time zone; Define office hours; Defer, do not drop; Test a date-line case. If a step has no owner, leave the workflow off. An unnamed step becomes a message nobody checks.

Save the before and after where the team already works. Note one mistake in a sentence someone can act on: a missing field, a wrong destination, or a line that should have waited for a person. Do not add another tool in the same sitting. Next week, fix only that mistake and run five more real cases. A workflow that survives those five is ready to connect to the rest of the office.

Questions people ask before they start

Can we send whenever and let people mute us?

You can, and a share of them will mute the number entirely, including the messages you send at a fair hour. The window is cheaper than rebuilding trust.

What about urgent alerts?

Define urgent separately: a system down for your own staff can ignore customer hours. A payment reminder is not urgent. Do not let one flag bypass the window for everything.

Whose hours, ours or theirs?

If they must act, use their zone. If only your office must act, use yours. Write it in the runbook so the next edit does not flip it.

How do we start without a large project?

Use one real case, one owner, and the steps for Time Zones and Office Hours in a Scheduled Job. Expand only after five more cases pass with that same owner. A larger build before that test usually adds screens the team will not open.

How MadniSofts can help

Store a region time zone, send only inside the hours you would be willing to receive, and defer the rest to the next opening without sending twice. You can review MadniSofts automation and scraping, or talk to the team from the homepage.