Widget

Status-page time stamper

Your incident timestamps are in UTC. Your customers are not. Drop this 2 KB script on your status page and every <time> element with a datetime attribute auto-renders in the viewer's local timezone — with optional relative-time labels.

Format

Live preview

⚠️ Incident opened: Tue, 21 Apr 2026 21:32:12 GMT

✅ Incident resolved: Thu, 23 Apr 2026 16:32:12 GMT

📢 Last update: Thu, 23 Apr 2026 21:32:12 GMT

1. Add the script

<script async src="https://worldclocktools.com/embed/status-time.js"></script>

2. Mark up your timestamps

<time datetime="2026-04-23T14:30:00Z" data-wct-time>
  Apr 23, 14:30 UTC
</time>

Any <time> with a valid ISO datetime and the data-wct-time attribute will be rendered in the viewer's locale. The script re-scans on DOM mutations so it works with React, htmx, and incremental updates.

Free for all non-commercial and commercial use — backlink to worldclocktools.com appreciated. No tracking, no analytics; the script never phones home.

Questions

FAQ

Does the script make any external requests?: No. The entire script is self-contained — it reads your <time> elements, formats them via the browser's built-in Intl API, and updates the DOM. It never phones home, doesn't load any data, and doesn't track viewers. The only network request is the one-time fetch of the script itself.
How does it handle relative-time updates?: If you set data-wct-format to "relative" or "both," the script re-renders matching <time> elements once per minute. That keeps labels like "5 minutes ago" accurate without flickering. If you don't need relative time, leave the format at the default "local" and there's no recurring work.
Does it work with React, htmx, or other frameworks that mutate the DOM?: Yes. The script attaches a MutationObserver to the document body, so any <time> elements added later (after a route change, after an htmx swap, after a React state update) are found and rendered in the next tick. You don't need to call any function manually.
Can I use this for incident timestamps that need to update in real time?: Yes — that's the original use case. The script formats based on whatever ISO string is in the datetime attribute, so as long as your status page sets the datetime correctly when an incident updates (most platforms do), the rendered local time follows automatically.

Related tools

FAQ

Does the script make any external requests?

No. The entire script is self-contained — it reads your <time> elements, formats them via the browser's built-in Intl API, and updates the DOM. It never phones home, doesn't load any data, and doesn't track viewers. The only network request is the one-time fetch of the script itself.

How does it handle relative-time updates?

If you set data-wct-format to "relative" or "both," the script re-renders matching <time> elements once per minute. That keeps labels like "5 minutes ago" accurate without flickering. If you don't need relative time, leave the format at the default "local" and there's no recurring work.

Does it work with React, htmx, or other frameworks that mutate the DOM?

Yes. The script attaches a MutationObserver to the document body, so any <time> elements added later (after a route change, after an htmx swap, after a React state update) are found and rendered in the next tick. You don't need to call any function manually.

Can I use this for incident timestamps that need to update in real time?

Yes — that's the original use case. The script formats based on whatever ISO string is in the datetime attribute, so as long as your status page sets the datetime correctly when an incident updates (most platforms do), the rendered local time follows automatically.