You can send communication at any time but if your messages don’t get to your customers at the right time, they won’t be effective. Think of multitude of this issue if you have common operating paradigm with no brand and no market isolation with shared AEP/AJO instance for global implementation.
With no isolation of data and operating groups it will be very tricky to send some communications based on consumer active time + time zone.
Lets chime in to a use case: Consider an operating model in which a marketing or operations team works from a single geolocation in a single time zone and must plan a campaign that takes into account the user's active time of the day and the time zone they are in (where they have consumers from multiple geos).This would be tricky to orchestrate campaigns based on consumers active time + time zone and in some situations due to time zone differences we might have to send the communication next day's based on next days active time + time zone as consumer is out of today's.
Key Prerequisites
- Add in Preference Details to you XDM profile Schema

Implementation
Consider this as a blueprint with a simple orchestration that to sent a communication at 10 AM considering consumers local timeZone and this can be extended more complex use cases.

Step 1: This is simple and would be your audience for the journey.
Step2: Condition check of timezone field existences in profile check (make sure timezone data is available before global segmentation job)

- code to check that profile contains timeZone data existence, this is need as wait for logic how to compute.
isNotEmpty(#{ExperiencePlatform.ProfileFieldGroup.profile.timeZone})
Step3 : TimeZone Based Delay Addition

- Code for the wait condition, the if statement check against profile timeZone current hour that it has passed 10 AM in that time zone or not, if true we are adding one more day for scheduling else we do same day scheduling. Note: the return DateTimeOnly is the local time when email be will triggered by AJO.
if (toInteger(substr(toString(updateTimeZone(now(),#{ExperiencePlatform.ProfileFieldGroup.profile.timeZone})),11,13)) >= 10)
then
(toDateTimeOnly(toDateTime(concat(substr(toString(nowWithDelta(1,"days")), 0, 10),'T10:00:00.000Z'))))
else
(toDateTimeOnly(toDateTime(concat(substr(toString(now()), 0, 10),'T10:00:00.000Z'))))
Step4: Fallback TimeZone Based Delay Addition

- Code for the wait condition, the second wait if statement check against fallback time zone (this should be same as journey timeZone, please check the hard code vlaue of "Asia/Calutta") current hour that it has passed 10 AM in that time zone or not, if true we are adding one more day for scheduling else we do same day scheduling.
if (toInteger(substr(toString(updateTimeZone(now(),"Asia/Calcutta")),11,13)) >= 10)
then
(toDateTimeOnly(toDateTime(concat(substr(toString(nowWithDelta(1,"days")), 0, 10),'T10:00:00.000Z'))))
else
(toDateTimeOnly(toDateTime(concat(substr(toString(now()), 0, 10),'T10:00:00.000Z'))))
Step5 : Final step for verifying email, below block helps to get the email triggered time in local time.
<p>Profile Time Zone:{{profile.timeZone}}</p>
<p>Current UTC time: {%= getCurrentZonedDateTime() %}</p>
{%#if isNotEmpty(profile.timeZone)%}
<p>converted to profile time zone: {%= convertZonedDateTime(getCurrentZonedDateTime(), profile.timeZone) %} </p>
{%else%}
<p>converted to profile time zone: {%= convertZonedDateTime(getCurrentZonedDateTime(), "Asia/Calcutta") %} </p>
{%/if%}
Remember to keep the fallback timeZone in step 4 same as journey timeZone to avoid unknown surprises. This blueprint can be used to orchestrate more complex workflows of this kind.
Reach out if you have complex use case likes this in our organizations or for understanding of this article.
~cheers.
NN.