Work Approach Pricing Notes Contact

Morning report in the client's timezone: how not to mess up UTC

When the client is in Vladivostok and the server is UTC, you need to explicitly calculate the offset. How to set up cron in Make accounting for DST, and how to verify the report arrives on time.

All notes

Vladivostok is UTC+10 and doesn't observe daylight saving time. So a 9:00 AM report means triggering at 23:00 UTC the previous day. Simple enough — until you forget it and the client asks why the report arrived at 7 PM.

Setting cron in Make

Make's scheduler uses UTC. Calculate your offset manually: target local time minus UTC offset = UTC trigger time. For UTC+10 and 9:00 AM local: 9:00 - 10:00 = -1:00 → 23:00 UTC previous day.

Set the Make scenario schedule to run at 23:00 UTC every day.

Verifying it works

Don't just trust the math. Run the scenario manually, check the Telegram message timestamp in the client's chat, and confirm it matches 9:00 AM their local time. Make's execution history shows the UTC run time — cross-reference it.

DST note

Vladivostok doesn't do DST, which makes this easy. For European or US clients, you'll need to update the cron offset twice a year, or use a date formatting function that handles timezone conversion dynamically in Make.

The cleanest approach for DST-sensitive clients: use Make's formatDate(now; "HH:mm"; "America/New_York") to check the local time at runtime, rather than relying solely on a static cron offset.

Have a similar process?

Tell me where leads, money or manual time are leaking. I'll look at what can become a system.

DM on Telegram