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.

Last updated recently. This builder is documented in English and stays follow-only in other locale shells until widget instructions are localized.

Format

Live preview

⚠️ Incident opened: Fri, 05 Jun 2026 22:00:48 GMT

✅ Incident resolved: Sun, 07 Jun 2026 17:00:48 GMT

📢 Last update: Sun, 07 Jun 2026 22:00:48 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.

Implementation notes

Where the status-time widget is trustworthy

This widget is meant to make already-correct UTC timestamps easier for humans to read, while leaving the original machine-readable datetime intact.

What it touches

The script reads existing <time> elements with datetime attributes and updates their visible label. It does not need a database, login, or server-side integration.

Best fit

Status pages, incident reports, changelogs, and release notes where UTC timestamps are accurate but readers need local-time interpretation.

Failure mode

If JavaScript is blocked, the original timestamp remains visible. That fallback is intentional because the source datetime stays in the HTML.

Boundary

Use it for timestamp presentation, not legal audit trails. Keep the canonical UTC value in the datetime attribute so downstream systems can parse the original time.

This builder page explains the implementation. The generated script/embed endpoint remains a utility endpoint, not a standalone documentation page.

Reference data for status-page time

Reference fields include the widget name, UTC/local-time workflow, fallback behavior, and FAQ text.

statuspagetimestamperutctimestampviewerlocaltimezonerelativetimelabelstimedatetimeattributeincidenttimestampschangelogreleasenotesnoaccountnocookiesdoesthescriptmakeanyexternalrequestshowdoesithandlerelativetimeupdatesdoesitworkwithreacthtmxorotherframeworksthatmutatethedomcaniusethisforincidenttimestampsthatneedtoupdateinrealtimestatuspagepagetimetimestamperstamperutctimestampviewerviewerlocallocaltimezonetimezonerelativerelativetimetimelabelslabelstimetimedatetimedatetimeattributeattributeincidenttimestampschangelogchangelogreleasereleasenotesaccountnocookiesdoesthescriptscriptmakeanyexternalexternalrequestsrequestsnotheentireentirescriptscriptisselfcontainedcontaineditreadsyouryourtimetimeelementselementsformatsformatsthemthebrowserbrowserbuiltandupdatesupdatestheneverphonesphoneshomehomedoesndoesnloadanddoesndoesntracktrackviewersviewerstheonlynetworknetworkrequestrequestistimefetchscriptitselfitselfhowithandlehandlerelativetimeupdatesupdatesifwctformatformattotorelativerelativeorscriptrererendersrendersmatchingmatchingtimeelementsonceperminuteminutethatthatkeepskeepslabelslabelslikelikeminutesminutesagoagoaccurateaccuratewithoutwithoutflickeringflickeringifneedrelativetimeleaveleavethetheformatformatatthedefaultdefaultlocal

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

Status-page time stamper

Last updated recently. This builder is documented in English and stays follow-only in other locale shells until widget instructions are localized.

Where the status-time widget is trustworthy

This widget is meant to make already-correct UTC timestamps easier for humans to read, while leaving the original machine-readable datetime intact.

What it touches

The script reads existing <time> elements with datetime attributes and updates their visible label. It does not need a database, login, or server-side integration.

Best fit

Status pages, incident reports, changelogs, and release notes where UTC timestamps are accurate but readers need local-time interpretation.

Failure mode

If JavaScript is blocked, the original timestamp remains visible. That fallback is intentional because the source datetime stays in the HTML.

Boundary

Use it for timestamp presentation, not legal audit trails. Keep the canonical UTC value in the datetime attribute so downstream systems can parse the original time.

This builder page explains the implementation. The generated script/embed endpoint remains a utility endpoint, not a standalone documentation page.

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.

Status-page time stamper

Where the status-time widget is trustworthy

What it touches

Best fit

Failure mode

Boundary

FAQ

Related tools

Never miss a launch, finale, or eclipse.

Status-page time stamper

Where the status-time widget is trustworthy

What it touches

Best fit

Failure mode

Boundary

FAQ

Related tools