Articles · Remote work & small tools

Working across time zones without losing your mind

Small habits, three browser tabs, and the few traps you only need to learn once—so the next missed meeting isn't because somebody did time zone arithmetic in their head.

The quietest disaster in remote work goes like this. You and a coworker in another country agree on a 9am meeting. The calendar invite looks fine. The day before, daylight saving time flipped on their side, and half the invite is now off by an hour. Nobody notices until 9:03, when the wrong person joins the wrong call—and at that point all you can do is apologize.

Time zones don't create newbugs. They expose the ones already in our heads. After a few missed calls and "wait, is 9am yours or mine?" threads, most people end up with a very short list of habits and an even shorter list of browser tabs that take this off the daily mental load.

Anchor everything on one absolute instant

If you remember one thing: a meeting exists at one absolute moment, regardless of whose calendar is reading it. The unambiguous ways to write that moment are UTC or a Unix timestamp. Everything else ("8pm Berlin time," "next Tuesday morning," "Friday EOD") is a translation, and different people translate it differently.

You don't need to make humans read UTC. You just want your invites, tickets, and log lines anchored on a definite instant under the hood, then translated into a friendly local form when a person looks at it. Store and transport in the deterministic version. Display the friendly version.

A few small habits that block most of the bugs

  • Always include the zone when you write a time. "Tuesday 9am PT" is fine; "Tuesday 9am" across teams is a coin flip.
  • Double-check recurring meetings on DST week. Different countries flip on different dates. Calendar apps usually handle this; an old exported ics someone is still using might not.
  • Prefer ISO 8601 in tickets and scripts. 2026-04-29T01:30:00Z means the same thing to every person and every parser. 04/29/26 01:30 does not.
  • Keep one converter tab pinned next to your calendar. When you're unsure, paste and look. Five seconds beats a 30-minute apology email.

Three small tabs that handle 90% of the friction

Each runs in your browser; you give it one input and copy back one result without re-thinking the rules.

Time zone converter — "what time is it for them?"

Pick an instant, pick the other side's zone, read the result. Use it before sending an invite, and put both sides' times in the body. People misread "9am PT / 12pm ET / 6pm CET" less often than a single number.

👉 /tools/timezone

Unix timestamp converter — logs, token expiry, APIs

Logs and tokens are full of integers like 1745886000. Paste it; see local and UTCat once. A webhook fired at "2am"—whose 2am? When does this JWT actually expire? Paste and find out.

👉 /tools/timestamp

ISO 8601 duration — retries, caches, SLAs

Strings like PT15M, P1DT2H, and PT0.5Sshow up in calendars, Kubernetes, OpenAPI, and a hundred config files. Paste one, see "15 minutes" or "1 day, 2 hours," and confirm the policy you actually wrote.

👉 /tools/iso8601-duration

A few traps you only need to learn once

  • Seconds vs milliseconds.Most APIs use seconds; lots of JavaScript hands you milliseconds. A converter that accepts both saves you from the "why is it 1970?" minute.
  • Half-hour and 45-minute offsets are real. India, Newfoundland, Iran, Nepal, parts of Australia. Scheduling code that quietly rounds to whole hours will quietly miscount those users.
  • "Floating" events.Some recurring events ("I do yoga at 7am local, even when traveling") are intentionally not anchored to UTC. Most DST week calendar bugs are floating events being treated like anchored ones.
  • Cron is not a time zone. A cron expression is just fields; the time zone is decided by who runs it—usually UTC, sometimes server local. When you're unsure, paste it into a cron explainer and read the next few fire times. /tools/cron

When to reach for which tool

  • Booking a meeting → time zone converter, write both sides' times in the invite body, attach the ics so calendars can re-anchor.
  • Reading a log or token → Unix timestamp converter, local + UTC in one shot.
  • Writing a config or ticket → ISO 8601 for instants, PT… for durations. The duration tool is the fastest way to confirm what you actually wrote.
  • Counting calendar days, business days, birthdays→ this isn't really a time-zone problem; use the date difference calculator and get days/weeks/months/years between two dates without doing month-length arithmetic in your head. /tools/calculators/date-difference

The short version

Time zones aren't going away, and DST will keep flipping on weekends people forget. The job is small: drop the cost of "what time is it for them?" from a 10-minute head calculation to one tab.

Anchor on UTC, write ISO 8601 where it matters, and keep a converter pinned next to your calendar. The next time you join the wrong meeting, at least it won't be because of arithmetic.

If you want one place to keep these tabs: Unix timestamp, time zone converter, ISO 8601 duration, and cron explainer all run in your browser on Toolcore. Start from the home catalog or /about for the full map.

Common use cases

  • Share with a remote team that keeps booking meetings off by an hour around DST week.
  • Pin three browser tabs (timestamp converter, time zone converter, ISO 8601 duration) next to your calendar.
  • Use the FAQ if you only have a minute; the body covers the same ideas with more context and links.

Common mistakes to avoid

  • Writing times without a zone

    “Tuesday 9am” across teams is a coin flip. Always include PT, ET, CET, JST, or use ISO 8601 with a Z or offset.

  • Treating cron as a time zone

    A cron expression has no zone of its own; the runtime decides. When you’re unsure, paste it into a cron explainer and read the next few fire times.

  • Quietly rounding offsets to whole hours

    India, Newfoundland, Iran, Nepal, parts of Australia use half-hour or 45-minute offsets. Scheduling code that rounds will quietly miscount those users.

FAQ

Should I store all my times in UTC?

For storage and APIs, yes. Display in local time. The exception is “floating” events (like a daily local-time activity) that should not be anchored to UTC at all.

What about half-hour or 45-minute offsets?

They are real—India, Newfoundland, Iran, Nepal, parts of Australia. Pick a converter that handles non-whole-hour offsets so you don’t miscount users in those regions.

Do the converters on Toolcore upload my input?

No. The Unix timestamp converter, time zone converter, ISO 8601 duration tool, and cron explainer all run in your browser tab; the page does not send the input to a server.

How do I confirm what a cron expression actually runs?

Open the cron explainer on Toolcore, paste the expression, and check the next few fire times—plus confirm whether it’s being interpreted in UTC or another zone.