Guides

Times that work everywhere with UTC, offsets, time zones, and Discord timestamps

"8pm PST" is compact, but it is not always the safest thing to send.

I use different time formats depending on where the message is going. Discord needs a timestamp. A calendar invite needs a real timezone. A support handoff often needs the original time plus the local answer.

Examples to try

The trap

A time can be correct and still be bad to send. Conversion is only one check. The next person also has to understand the same instant.

A fixed offset like "UTC-7" describes one offset from UTC. It does not describe the daylight-saving rules for Los Angeles. For a future one-off event, it may be enough. For a recurring meeting, it is a bad source of truth.

Timezone abbreviations have the same problem in a different form. "CST" can mean Central Standard Time, China Standard Time, or Cuba Standard Time. If I see it in a meeting thread, I check it before replying.

What I use

This is the table I keep in my head before sending a time. The right answer depends on the place where the time will be read.

FormatUse it forWatch out for
Plain local timeMessages where everyone is in the same placeBreaks as soon as the thread includes another region
UTCTechnical logs, release notes, incident notes, global reference timesNormal readers still need their local date and time
UTC offsetOne exact instant when the offset is already knownNot a timezone. Bad for recurring meetings and daylight saving changes
City or IANA timezoneCalendar invites, recurring meetings, future event planningLonger to write, but it preserves daylight-saving rules
Discord timestampDiscord events, community calls, launches, countdownsOnly works inside Discord, but it works well there
Calendar inviteFinal meeting source of truthStill worth checking before you send the invite

What I use by situation

For Discord events, I use a Discord timestamp. One tag renders in each reader's local time, and the relative format works for countdowns.

For Slack or email, I usually include the original phrase and the converted local answer, like "Friday 8pm PT / Saturday 11am Singapore." That keeps the sender context and gives the answer to the person reading.

For public event pages, I prefer the city or IANA timezone and a few converted examples for common audiences. If the event is near midnight, I include the local date.

For technical logs, UTC is fine. I still convert it when I am explaining the incident to a human who is not reading raw timestamps all day.

Checklist before sending

These are the checks I run before I post a time for other people.

  • Include the date, not just the hour.
  • Avoid bare abbreviations like CST or IST when the audience is international.
  • Use a city or real timezone for future dates and recurring meetings.
  • Use Discord timestamp syntax for Discord announcements.
  • Convert UTC into local time when the reader is deciding whether they can attend.
  • Check whether the converted time is yesterday or tomorrow for someone else.

Quick answers

Is UTC enough for sharing event times?

UTC is a good reference, especially for technical audiences. For normal event readers, include a local-time conversion or a platform timestamp so they do not have to do the conversion themselves.

Is UTC-7 the same as Pacific Time?

No. UTC-7 is a fixed offset. Pacific Time is a timezone with daylight-saving rules, so the offset can change depending on the date.

What is the safest time format for Discord events?

Use Discord's full date and time timestamp format. Discord renders it in each reader's local timezone.

More timezone guides

bf259e4