Product Decisions This Supports
- Admin experience polish, not product surface. This package only touches the Laravel Nova dashboard — it informs decisions about internal tooling UX (operator situational awareness), never customer-facing roadmap. Treat it as an ops-ergonomics line item, not a feature bet.
- Distributed-team coordination use cases. Concretely supports: release/launch window planning across regions, on-call and support-coverage handoffs, "is the EU team online yet?" checks before routing a ticket, and deadline sanity-checking for globally-scoped commitments.
- Build vs. buy, resolved cheaply toward "adopt" — with a new platform precondition. The alternative is 1–3 days of engineering to hand-roll an equivalent Nova card plus ongoing ownership. A MIT-licensed, config-only card is still the correct default, but 3.4.0 raises the floor: PHP 8.4 is now the minimum supported version (was 8.3). Adoption is no longer a pure "install and go" — it's coupled to your runtime upgrade schedule.
- Runtime baseline coupling is the real cost, not the code. Adopting 3.4.0 means either you are already on PHP 8.4+, or you commit to getting there. If your fleet is on 8.3 (common for Laravel 11 estates), the decision is "pin 3.3.1 and revisit," not "adopt." Do not let a dashboard clock card become the forcing function for a PHP upgrade — sequence the upgrade on its own merits.
- Roadmap de-prioritization signal — unchanged. With 8 stars, 0 dependents, and a single narrow capability, this is not a strategic dependency. It should never appear on a roadmap as a deliverable; it appears as a "while we're in there" improvement to an existing admin sprint.
- Maintenance-posture signal, upgraded slightly (still not a guarantee). 3.4.0 is genuine hygiene work: webpack pinned to stop a broken asset build, a CVE swept up (CVE-2025-68157,
HttpUriPlugin redirect bypass — only reachable with experiments.buildHttp, which this package does not use), coding-standard tooling, and Laravel 13 / PHP 8.5 CI groundwork. That is a maintainer paying attention. It does not change the bus factor of one, but it does mean "abandoned" is not the current risk — "slower than your upgrade cadence" is.
- Version-pinning policy, now evidence-backed. A minor version bump (3.3.1 → 3.4.0) shipped a breaking platform requirement. That is a concrete argument for pinning this dependency exactly rather than floating
^3, and for treating admin-panel dependencies as a reviewed lockfile entry.
- Risk budget allocation. Useful as a worked example when setting policy for third-party admin-panel dependencies: low blast radius, MIT, easily forked or replaced — the category where you can accept a lower maintenance bar than for anything in the request path. Note the build-toolchain (npm/webpack) surface is real but build-time only; it never touches runtime or the request path.
- Does not support: pricing/geo decisions, customer timezone handling, scheduling or meeting-booking features, or any compliance/SLA determination. Those need real services, not a clock card.
When to Consider This Package
Consider it when all of the following hold:
- You already run Laravel Nova in production. This is a Nova card; it is inert anywhere else.
- You are on PHP 8.4 or later, or have a committed date for it. This is now a hard gate for 3.4.0+. If you are on 8.3, you can still run 3.3.1 — but you are pinned to an older line and should treat the upgrade as a scheduled follow-up, not a permanent state.
- Your operators or support staff are spread across two or more time zones and currently context-switch to a browser tab or OS widget to check local times.
- You want zero-maintenance, config-driven display — no API keys, no external service, no data to model beyond a list of cities and labels.
- MIT licensing is compatible with your distribution model, and you're comfortable vendoring/forking a small UI component if it goes stale.
- The cost of it breaking is a cosmetic gap in an internal dashboard — i.e., the failure mode is acceptable.
Look elsewhere (or stay pinned) when:
- Your runtime is PHP 8.3 and PHP 8.4 is not on the near-term plan. Stay on 3.3.1 if you already use it; do not start a new adoption at the old pin, because you are buying into a version that will drift from upstream fixes. There is no security urgency here — the CVE addressed in 3.4.0 is not reachable by this package.
- You are not on Nova (Filament, plain Blade, Inertia, or a separate ops tool). The port cost exceeds the value.
- You need user-facing timezone conversion, meeting scheduling, or calendar integration — that's a product feature with real requirements, not a dashboard ornament.
- You need on-call rotation, SLA clocks, or incident timers. A world clock is not a paging tool, and conflating them is a common and expensive mistake.
- You require vendor support, an SLA, or a security review trail. At 8 stars and 0 dependents the bus factor is effectively one; budget for the possibility you own the fork.
- You need deep localization or accessibility guarantees beyond what a small community card provides — verify against your own bar rather than assuming.
How to Pitch It (Stakeholders)
For executives (one paragraph): This is a small, free, open-source add-on for the internal admin panel our team already uses. It puts a row of world clocks on the dashboard so staff coordinating across regions stop guessing what time it is for colleagues in Berlin or Bangalore — fewer mistimed handoffs, fewer "sorry, I was asleep" gaps around launches and support coverage. Cost is a few hours of setup, there is no vendor contract or data-sharing, and if it ever stops working the impact is a cosmetic gap in an internal tool, not a customer-facing outage. One caveat worth flagging: the latest version requires PHP 8.4, so this should be sequenced after our runtime upgrade rather than used to justify it. Recommendation: approve as an admin-tooling housekeeping item, not as a roadmap initiative.
For engineering (the honest summary): A Laravel Nova card, MIT, ~8 stars, zero dependents, single-purpose: render a configurable list of world clocks in the Nova dashboard. No services, no migrations, no runtime dependencies on the request path — install, publish config, list your timezones, done. 3.4.0 is a breaking release despite the minor version number: PHP 8.4 is now the minimum (was 8.3), with Laravel 13 groundwork and PHP 8.5 in CI. It also pins webpack (asset compilation was broken by laravel-mix floating webpack: ^5.60.0 against webpack 5.107.0), sweeps CVE-2025-68157 — not reachable here, it needs experiments.buildHttp — and adds a coding-standard chain. Practical guidance: (a) pin the exact version, don't float ^3, given a minor bump carried a breaking platform change; (b) if we're on PHP 8.3, hold at 3.3.1 and revisit after the runtime upgrade — no urgency; (c) it is still a one-maintainer project, so be prepared to fork or replace rather than file issues and wait; (d) it is presentation-only, so it belongs in a config file, not in application code; and (e) it should not be allowed to become the de facto answer to a scheduling problem we haven't actually scoped. Estimate: half a day including review, plus whatever the PHP 8.4 move costs independent of this card.