Nova Time Field Laravel Package

Product Decisions This Supports

• Build vs. buy for a single admin-UI primitive. The decision on the table is whether to spend 1–3 engineer-days building a custom Nova Vue field — picker UX, 12/24-hour formatting, seconds/step handling, null/clear semantics, styling, tests — or adopt a free MIT package that already ships it. For most teams the math favors adoption; building only wins if you need behavior the package deliberately doesn't expose.
• Roadmap scoping for time-of-day workflows. This unblocks features that need a time without a date: opening hours, shift start/end, appointment slots, delivery windows, class timetables, service availability, and same-day order cutoffs. It answers the planning question "can we ship time capture this sprint without a field-framework project?" — usually yes, with hours of integration for the first screen and minutes for each one after.
• Where time entry lives: back office vs. customer surface. This is a form control, not a scheduling engine. It lets you draw a clean boundary — naive time entry inside Nova for internal operators, while timezone math, recurrence, availability, and conflict detection stay in application code or a dedicated service. That keeps lock-in low and insulates the customer product from admin-panel risk.
• A data-model commitment, made explicitly. Adopting it implies storing a wall-clock TIME value (e.g. HH:mm:ss) and interpreting timezone at the business-logic layer — as opposed to a DATETIME instant or a duration in minutes. Recording that call before feature work matters more than the field choice, because reversing it later is a data migration, not a field swap.
• Dependency-risk posture for admin tooling. Thirteen stars, zero dependents, and a single maintainer is a weak popularity signal. The mitigations are real: MIT license, a thin presentational footprint confined to the Nova SPA, and a 2026-05-06 release suggesting the maintainer is tracking Nova majors. That combination supports a "pilot, pin, and be ready to fork" decision rather than blocking on adoption metrics.
• Upgrade planning against a paid, fast-moving target. Because Nova is commercial and ships breaking Vue/Tailwind/tooling changes, this field becomes a line item in every Nova upgrade checklist. The PM decision is to own that explicitly: pin the version, smoke-test admin forms on upgrade, and retire the dependency the moment Nova ships a native equivalent.
• Scope discipline for "scheduling" requests. Stakeholders asking for time-of-day capture often conflate it with availability logic. This package gives you a credible, cheap answer to the narrow ask and a defensible line to hold on the broader one.

When to Consider This Package

Adopt when:

• You run Laravel Nova and need a time-only input your installed version doesn't cover cleanly with native date/datetime fields — verify against your actual release, since that gap may close in a future major.
• The field lives on internal/admin surfaces, where a broken input degrades operations but never reaches the customer product. Blast radius is contained and revert is a one-line field swap.
• You have a Laravel/Vue-fluent engineer who can audit a small Nova field in an afternoon and fork it if upstream goes quiet — the MIT license makes that legally and technically trivial.
• You want a fast pilot: composer require, one resource wired, ops feedback, decision in days.
• Your requirements are standard time-field ergonomics — picker, format handling, null/clear — with no exotic behavior.

Look elsewhere or build when:

• You need timezones, recurrence (RRULE), durations, or availability/conflict logic. That's a domain problem; pair a field with a real scheduling library or service rather than expecting it from a widget.
• The input is customer-facing or revenue-critical and needs guaranteed accessibility, localization, and support SLAs a 13-star package can't promise.
• Your Nova version already has a suitable native time field — don't add a dependency out of inertia.
• You have no capacity to own a fork and the field sits on a critical path. Prefer in-house code or a broadly adopted alternative with active maintainers.
• You need database-level guarantees — constraints, indexed range queries over time windows. Design the schema independently of the field; the package provides none of that.

Due diligence before merging: confirm composer.json constraints match your exact Nova/Laravel/PHP matrix (not the README's claim); audit the source for the storage contract, timezone/DST behavior, and whether compiled JS assets ship with the package; test against your 12/24-hour locale and null-handling requirements (clearing must persist NULL, not 00:00:00); check the issue tracker for unresolved Nova-major breakages; and record a named owner plus a fork/vendor path in your dependency inventory.

How to Pitch It (Stakeholders)

For executives (30 seconds): Operations needs to record times of day — shift starts, opening hours, order cutoffs — in our admin panel. Rather than spend engineering days building a custom form control, we can adopt a free, MIT-licensed Nova field that is still receiving releases this year. Integration is a few hours for the first screen and minutes thereafter. The risk is low and bounded: it's a thin presentational layer that touches only internal admin screens, never the customer product, and we can copy it into our own codebase at any time if upstream stops. Recommendation: approve a short pilot on one low-traffic resource, pin the version, assign an internal owner, and revisit at our next Nova upgrade.

For engineering (the real trade-off): This buys us the input widget and nothing else — it is not a scheduling system. Integration is composer require, a use in the resource, Time::make('opens_at', 'opens_at')->nullable(), and a smoke test that a submitted value round-trips as HH:mm:ss and that clearing it stores NULL rather than midnight. The audit surface is small — one Field subclass plus a Vue component, roughly an hour to read — which is also the reason we can fork it if we have to. Own the parts the package correctly refuses to own: a stable machine-readable storage format, validation rules (date_format:H:i:s) applied consistently project-wide, cross-field logic like "close must be after open" at the request level, and any timezone/DST interpretation in a model accessor rather than in $casts. Two known sharp edges: '00:00:00' is falsy in PHP, so never test a time column with empty(); and HH:mm:ss sorts lexicographically, which is why ->sortable() works — change the storage format to g:i A and sorting and range queries silently break. Add "open every resource using this field" to the Nova upgrade checklist, because compiled asset breakage shows up as a blank widget, not a failing test.