In this article
A time can be written so that each person reads it on their own clock. Instead of typing a time and a zone and hoping, the message carries the moment itself and every reader sees it converted to wherever they are.
One small change that removes the most reliable source of confusion in any group with people in more than one country.
What you will be able to do
- check_circle Announce a time that converts itself.
- check_circle Say what each reader actually sees.
- check_circle Write the rest of the sentence so it still helps.
- check_circle Know where it stops working.
The same message, read in three places, showing three different clock times.
calendar_month A typed time is a time in your own head
Write "Thursday at two" in a group with people in four countries and you have not announced a meeting, you have set a puzzle. Some will assume your zone, some will assume their own, one will convert it wrongly, and at least one will ask — which produces a thread of corrections that is longer than the original message and still leaves somebody confused.
Adding the zone does not fix it. "Two o'clock, my time" asks every reader to do arithmetic involving a number they may not know, at a moment when they are half-reading a chat. Most will get it right; the ones who do not will arrive an hour out and nobody will find out until it happens.
What actually fixes it is sending the moment rather than the description. The message carries a point in time and each client renders it in the reader's own clock, which means nobody converts anything and nobody can convert it wrongly.
What does the reader actually see?
The time in their own zone, as an ordinary part of the message, without any indication that it was converted. That is the point — there is nothing for them to do and nothing to notice. It also means somebody reading the chat in a screenshot or an export does not get the benefit, since the conversion happens in the app.
Should I still write the timezone?
Not as a conversion instruction, but it is often worth naming where the event is happening — "at the office", "the London call". That is different information: it tells people whose day this is and which clock the organisers are working to, which matters when somebody needs to ask a question outside the meeting.
Do I still need the day of the week?
Yes, and it is the thing most people drop once the app is handling the time. A converted moment can land on a different calendar day for a reader far enough east or west, so a date alone quietly disagrees with itself. The day of the week is also how humans check a plan against their own week — nobody reasons in dates.
Does it work in channels and captions?
It is part of the message, so wherever a message goes it goes too — which makes it most valuable in exactly the place time confusion is most expensive: a channel announcement read by an audience spread across the world, where nobody can ask a follow-up question and any ambiguity produces a hundred private messages.
Does it survive forwarding?
A forwarded message keeps its contents, so the converted time travels with it and renders correctly for whoever it reaches. What does not travel is anything you typed separately in a different message — which is one more argument for putting the time inside the announcement rather than in a follow-up.
Where does it stop helping?
When the reader is not where their device thinks they are, or will not be by the time the event happens. Somebody about to fly, somebody whose phone is set to a zone they left, somebody reading on a work machine configured elsewhere — all of them get a correct conversion to the wrong place. For anything involving travel, say where the event is as well as when.
schedule_send The rest of a good announcement
Getting the time right is one part of three. The others are cheap and routinely left out: what the thing is, in the first line rather than the fourth, and where it happens — a link, a room, a call — in the same message as the time rather than in a reply that scrolls away.
A second habit worth having is the reminder. However well an announcement is written, it was read four days before the event by somebody doing something else, and it is now a long way up the chat. A short message shortly beforehand, carrying the same time and the same link, does more for attendance than anything in the original.
settings Announcing a time
- Insert the time rather than typing it Use the composer's date control.
- Keep the day of the week in the text Dates alone are ambiguous.
- Name where the event is Not as a conversion hint.
- Put the link in the same message Replies scroll away.
- Say what it is in the first line Before the details.
- Send a short reminder beforehand The announcement is buried by then.
This page removes one ambiguity from an announcement. The curriculum step is the wider problem it belongs to: writing for an audience spread across languages and time zones without producing two versions of everything.
At a glance
- 1Time for everyone
Send a time that shows in each reader's own zone.
- 2Add the day
Write the weekday too; the date can shift.
- 3Travellers
People abroad see their current local time.
Updated
