# How to write time zones in an email so nobody misreads them > How to write a time zone in an email so nobody misreads it: time, zone and date, the reader's time first, ET vs EST, midnight, templates and a checklist. Source: https://timehint.app/blog/how-to-write-time-zones-in-email Priya works in Bengaluru. On a Wednesday afternoon she ends an email to Sarah in New York with "Can we talk at 9 tomorrow?" Sarah reads it over breakfast the same Wednesday and pencils in 9:00 AM Thursday, New York time. Priya meant 9:00 AM Thursday in Bengaluru, which was 11:30 PM on Wednesday for Sarah. Neither of them was careless. The sentence simply left out two facts. This guide shows how to write a time zone in an email so nobody has to guess. It covers the three things every time needs, whose time to put first, the abbreviations and midnight cases behind most missed meetings, how to write for a group spread across several zones, and how to convert a time someone sends you. Copy-paste templates and a checklist are at the end. ## How to write a time zone in an email: the short answer A meeting time in an international email needs three ingredients: the clock time, the time zone and the date. Add the reader's equivalent, and nobody has to do any math. > Thursday, September 17, at 10:00 AM New York time (7:30 PM in Bengaluru) Each part does a specific job: - **The clock time** says when. Include AM or PM, or use the 24-hour clock, and write the minutes when they aren't zero. - **The time zone** says whose clock. A city ("New York time") or a full name ("Eastern Time") is safer than a bare abbreviation, because several abbreviations name more than one place. - **The date** pins down the day. Words like "tomorrow" and "next Friday" depend on where and when the email is read. The date also fixes the time difference itself, since a daylight saving change between now and the meeting can move it by an hour. Here is the same invitation written three ways: | What you write | What can go wrong | |---|---| | "Can we talk at 9 tomorrow?" | No time zone, and "tomorrow" depends on the reader's day. | | "Can we talk at 9 AM IST tomorrow?" | IST names more than one place, and "tomorrow" is still unclear. | | "Can we talk on Thursday, September 17, at 9:00 AM Bengaluru time (Wednesday, 11:30 PM in New York)?" | Nothing to guess. It also shows at a glance that the time is bad for Sarah. | The last version is longer, but it's the only one that can't be misread. It also exposes the problem before anyone accepts: a time that is fine for you may be the middle of the night for them. ## Write the reader's time first, with yours in brackets When you email one person in another time zone, lead with their time and put your own in brackets. Priya's better email to Sarah reads: > Would Thursday, September 17, at 10:00 AM your time (7:30 PM for me in Bengaluru) work? There are three good reasons to do it this way: 1. **Readers act on the first time they see.** If it's already in their zone, they can check their day at once. 2. **You do the conversion once, carefully.** The alternative is the reader doing it in a hurry, on a phone, between meetings. 3. **Your time in brackets is a built-in check.** If you converted wrongly, the reader has what they need to notice. Lead with your own zone only when your clock is the fixed point: a webinar hosted from your office, or a deadline set by an organization in your country. Even then, give the reader's equivalent: "Applications close on Friday, September 25, at 5:00 PM London time (9:30 PM in Bengaluru)." ### How to write two time zones in one sentence Pick one pattern and use it for the whole email: - **City names in running text:** "10:00 AM New York time (7:30 PM in Bengaluru)". This is the clearest option for most emails. - **Abbreviations with a slash:** "10:00 AM ET / 7:30 PM IST". It's compact, but use it only when both abbreviations are unambiguous to both readers. - **24-hour times with cities:** "10:00 New York / 19:30 Bengaluru". Useful for international or technical readers. Format both times the same way. Don't pair "10am" with "19:30". Add a weekday to the second time only when the day differs, as in "4:00 PM Thursday in New York (8:00 AM Friday in Auckland)". That makes the change of date impossible to miss. ## ET, EST or EDT: which should you write? Many people write "EST" for any time in New York. For most of the year, that's technically wrong. EST means Eastern Standard Time, which is UTC−5. New York uses it only in winter. In summer the Eastern zone switches to EDT, Eastern Daylight Time, which is UTC−4. In 2026, New York is on EDT from March 8 to November 1. US daylight saving time runs from the second Sunday in March to the first Sunday in November, as [NIST](https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst) explains. So "3:00 PM EST" in September literally means 4:00 PM in New York. Most readers will assume you meant New York time and ignore the letter S. A careful reader, or a converter that takes the abbreviation at its word, will land an hour off. The fix is to drop the middle letter. **ET** (Eastern Time) means whatever New York's clock says on that date, so it's correct all year. "New York time" works just as well. The same applies across North America: | Zone (example city) | Winter | Summer | Safe to write | |---|---|---|---| | Eastern (New York) | EST, UTC−5 | EDT, UTC−4 | ET, or "New York time" | | Central (Chicago) | CST, UTC−6 | CDT, UTC−5 | CT, or "Chicago time" | | Mountain (Denver) | MST, UTC−7 | MDT, UTC−6 | MT, or "Denver time" | | Pacific (Los Angeles) | PST, UTC−8 | PDT, UTC−7 | PT, or "Los Angeles time" | One exception is worth knowing. Most of Arizona, including Phoenix, stays on Mountain Standard Time all year. In summer, "MT" can therefore mean two different clocks, and "Phoenix time" is the only unambiguous way to write it. The same logic applies in Europe. Central European Time (CET, UTC+1) becomes Central European Summer Time (CEST, UTC+2) from late March to late October. London is on GMT in winter and BST (British Summer Time, UTC+1) in summer, so "3:00 PM GMT" in July is an hour away from London's clock. "UK time" or "London time" avoids the problem. ## Abbreviations that mean more than one place Some abbreviations are ambiguous even when the season is right. Three cause most of the trouble in international email: | Abbreviation | Can mean | UTC offset | |---|---|---| | IST | India Standard Time | UTC+5:30 | | IST | Irish Standard Time (Ireland's summer time) | UTC+1 | | IST | Israel Standard Time | UTC+2 | | CST | Central Standard Time (North America) | UTC−6 | | CST | China Standard Time | UTC+8 | | BST | British Summer Time | UTC+1 | | BST | Bangladesh Standard Time | UTC+6 | A misread CST moves a meeting by 14 hours in winter. A misread IST can put a call in the middle of the night. Context usually tells you which is meant, but "usually" isn't good enough for a meeting invitation. When there's any doubt, write a city ("4:00 PM Dublin time") or a UTC offset ("16:00 UTC+1"). Both are unambiguous. There's a longer explanation of [IST, CST, BST and other ambiguous time zone abbreviations](https://timehint.app/blog/ambiguous-time-zone-abbreviations), including how to tell which meaning a sender intended. ## Midnight, noon and the next day Many readers aren't sure whether "12:00 AM" is the start or the end of a day. "Midnight on Friday" is worse, because people genuinely disagree about which side of Friday it's on. Here's how it goes wrong. Lukas in Berlin proposes a call at 5:00 PM on Friday, September 18. For Kenji in Tokyo, that's 12:00 AM on Saturday, September 19, the first minute of Saturday. If Lukas writes "midnight Friday your time", Kenji could reasonably read it as the start of Friday and turn up 24 hours early. A few rules remove the ambiguity: - **Avoid exactly 12:00 for meetings.** If the only slot is midnight for someone, it's a bad slot. Move it. - **For deadlines, use 11:59 PM or "end of day" plus a date and city.** "By 11:59 PM on Friday, September 18, Tokyo time" can't be misread. - **Write "noon" and "midnight" as words, with the date.** "Midnight at the start of Saturday, September 19 (Tokyo)" is clunky but exact. - **Spell out a change of day.** When a time crosses midnight for the reader, name their day: "9:00 AM Tuesday in New York (1:00 AM Wednesday in Sydney)". A bare "(next day)" works in a list, but a weekday is harder to overlook. ## 12-hour or 24-hour clock? Write times the way your reader reads them. The locale data that browsers and phones use, from the [Unicode CLDR project](https://cldr.unicode.org/), shows how conventions differ. It formats times with a 12-hour clock by default for US, Canadian, Australian and Indian English. It uses a 24-hour clock for British and Irish English, and for German, French and Japanese. In practice: - **Writing to a US reader:** use a 12-hour clock with AM and PM: "2:30 PM". The AP Stylebook prefers lowercase "p.m." with periods. Either is fine if you're consistent. - **Writing to readers in continental Europe or Japan:** "14:30" is natural and removes the AM/PM question entirely. - **Writing to a mixed group:** use 24-hour time, or give both once, as in "14:30 (2:30 PM)". Then stay consistent for the rest of the email. Whichever you choose, don't mix formats. "10am New York / 19:30 Bengaluru" makes the reader stop and check whether the two halves really describe the same moment. ## Writing to several time zones at once With one reader, you lead with their time. With a group, you can't put everyone first. Instead, choose one reference time zone, usually the organizer's city or UTC, and list each city on its own line in the order the day moves: > **Project check-in: Tuesday, November 3, 9:00 AM New York time** > > - London: 2:00 PM Tuesday > - Bengaluru: 7:30 PM Tuesday > - Tokyo: 11:00 PM Tuesday > - Sydney: 1:00 AM Wednesday A list like this does two jobs. Everyone finds their own line without converting anything, and the organizer sees the cost of the slot before sending it. Here the call lands late at night in Tokyo and after midnight in Sydney. That's a reason to pick another time, rotate the inconvenient slot from week to week, or split the call in two. The guide to [scheduling meetings across time zones](https://timehint.app/blog/schedule-meetings-across-time-zones) walks through those choices. Check for daylight saving changes between now and the meeting. One week earlier, on Tuesday, October 27, the same 9:00 AM New York slot is 1:00 PM in London and exactly midnight at the start of Wednesday in Sydney, because US clocks don't go back until November 1. If a recurring meeting crosses a clock change, send everyone the new local times for the weeks that move. The weeks to watch are listed in the guide to [the US and European daylight saving mismatch](https://timehint.app/blog/us-europe-daylight-saving-mismatch). One more habit helps a group: ask people to suggest alternatives in the same reference zone. "Could we do 10:00 AM New York time instead?" is easy for everyone to check. A reply that proposes "3pm my time" starts a new round of conversions. ## Converting a time someone sent you Reading a time is the mirror image of writing one. Most mistakes come from converting the right hour on the wrong date. Work through four steps: 1. **Work out which zone they meant.** A city or a full zone name is easy. An abbreviation needs a check against the tables above. If there's no zone at all, ask. 2. **Use the date of the meeting, not today's.** A daylight saving change in between can move the answer by an hour. 3. **Convert, then check the weekday.** Near the date line, the hour can be right and the day wrong. 4. **Confirm in both time zones.** A one-line reply catches a mistake on either side. Here's an example. Sarah in New York asks Lukas in Berlin, "Can you join at 3 PM EST on Thursday, September 24?" New York is on EDT in September. If Sarah means New York time, as nearly everyone who writes "EST" in September does, the call is at 9:00 PM in Berlin. If her "EST" is taken literally as UTC−5, it's 10:00 PM. Lukas shouldn't guess. He replies: "Just to confirm, that's 3:00 PM New York time, which is 9:00 PM for me in Berlin?" Any reliable converter will do the arithmetic, as long as you give it a city and the meeting date rather than an abbreviation and today. Some tools also do it inside your inbox. [Timehint](https://timehint.app/), for example, offers to rewrite a time you type in Gmail into a saved recipient's time zone. ## Put your time zone in your email signature A signature answers "where are you?" before anyone has to ask, and it's the first place a careful reader looks. Keep it short, and pick a format that stays true all year: ```text Priya · Product Lead Bengaluru, India (IST, UTC+5:30) ``` ```text Sarah · Project Lead New York (Eastern Time) · Usually online 9:00 AM–5:30 PM ET ``` ```text Lukas · Operations Berlin (Central European Time) ``` A few guidelines: - **Lead with the city.** Anyone can look up a city. Not everyone knows what an abbreviation stands for. - **Use a zone name that covers both seasons.** "Eastern Time" and "UK time" are right all year. In 2026, "EST" is wrong for New York for 238 days and "GMT" is wrong for London for 210 days. - **Use an offset only where clocks don't change.** India is UTC+5:30 all year, so Priya's line is safe. An offset for New York or Berlin would be wrong for months at a time. - **Add working hours if people often misjudge them,** in your own time zone, with the zone named. - **Update it when you move, or travel for a long stretch.** An out-of-date city is worse than none. ## Copy-paste templates Swap in your own cities, dates and times. Each template follows the rules above: the reader's time first, a weekday and date, and your own time in brackets. ### Proposing three times ```text Would one of these work for a 30-minute call? Times are in New York time, with Berlin time in brackets: - Tuesday, September 22, 9:00 AM (3:00 PM Berlin) - Wednesday, September 23, 10:30 AM (4:30 PM Berlin) - Thursday, September 24, 8:00 AM (2:00 PM Berlin) ``` ### Confirming a time ```text Confirmed for Thursday, September 17, at 10:00 AM New York time (7:30 PM for me in Bengaluru). I'll send the link beforehand. ``` ### Checking a time you're not sure about ```text You mentioned 3 PM EST on Thursday, September 24. Just to confirm, do you mean New York time? That would be 9:00 PM for me in Berlin. ``` ### Moving a recurring call around a clock change ```text A heads-up about next week: the UK changes its clocks on October 25 and the US on November 1. Our Tuesday call stays at 9:00 AM New York time, so on October 27 it starts at 1:00 PM in London instead of 2:00 PM. From November 3 it's back to 2:00 PM London time. ``` ### Setting a deadline ```text Please send your comments by Friday, October 2, at 6:00 PM Singapore time (noon in Berlin). ``` **How Timehint helps** **Offer your recipient's time while you write.** Timehint is a Chrome extension for Gmail. When you type a time with a zone, such as "5pm IST", in an email to a saved contact in Tokyo, a chip reads "5pm IST is 8:30pm JST for Kenji" with a **Use their time** button. Their time carries the zone's abbreviation or GMT offset. One click swaps in their time, and nothing you wrote changes without that click. When the conversion crosses midnight, the chip adds "next day". It stays quiet when your saved recipients are in different time zones. In emails you receive, a written time such as "5pm EST" can show your local time beside it. Read more about [converting time zones while you write an email](https://timehint.app/write-times-in-gmail). ## Checklist: before you send a time - [ ] The time has AM or PM, or uses the 24-hour clock. - [ ] It names a city or an unambiguous zone: ET rather than EST in summer, "Dublin time" rather than IST. - [ ] It has a weekday and a date instead of "tomorrow" or "next Friday". - [ ] The reader's time comes first, with mine in brackets. - [ ] Any change of day is spelled out with the reader's weekday. - [ ] Nothing is set for exactly midnight without a date and a city. - [ ] For a group, there's one reference zone and one line per city. - [ ] I've checked for a daylight saving change before the meeting date. - [ ] Every time in the email uses the same format. ## Frequently asked questions ### Should I write my time zone or the recipient's? Both, with the recipient's first. Their time lets them check their day at a glance, and yours in brackets lets them catch a conversion mistake. The exception is a fixed event run from your location, such as a webinar or an official deadline. Give that time first, then the reader's equivalent. ### Is it EST or ET, and is EST wrong in summer? EST is UTC−5, which New York uses only in winter. From the second Sunday in March to the first Sunday in November, the Eastern zone is on EDT, UTC−4, so "EST" in July is literally an hour off. Write ET or "New York time", which is correct all year. The same goes for CT, MT and PT. ### How do I write two time zones in one sentence? Put the reader's time first and yours in brackets, in the same format: "10:00 AM New York time (7:30 PM in Bengaluru)". If the day differs, name both days: "4:00 PM Thursday in New York (8:00 AM Friday in Auckland)". ### Should time zone names be capitalized? It depends on your style guide. As [The Editor's Manual](https://editorsmanual.com/articles/time-zones/) notes, the AP Stylebook capitalizes full names such as Eastern Standard Time, while The Chicago Manual of Style lowercases them. Abbreviations are written in capitals without periods: EST, CET, IST. City names are capitalized as usual. Choose one style and keep to it. ### What should I put in my email signature? Your city, plus a zone name that's correct all year, such as "New York (Eastern Time)" or "London (UK time)". If you're somewhere without daylight saving time, a UTC offset works too: "Bengaluru (IST, UTC+5:30)". Add your usual working hours if people often misjudge when you're available. ### When I email someone in a different time zone, what time do they see? The timestamp on your message appears in their own time zone, so it doesn't tell them your local time. Any time you type in the message appears exactly as written, which is why it needs a zone and a date. To go the other way and work out a sender's time from an email you received, see [how to see someone's local time in Gmail](https://timehint.app/blog/see-someones-local-time-in-gmail).