Doctrine Datetime Bundle Laravel Package

Product Decisions This Supports

• Scheduling, booking, and availability features. The package exists to map PostgreSQL date, datetime, and daterange columns into Doctrine entities. That directly enables product surfaces like resource booking, rental periods, subscription/validity windows, blackout dates, and pricing calendars where a half-open date interval is the natural domain model.
• Build vs. buy for temporal data modeling. This is a forcing function for a real decision: model intervals as two nullable DATE columns with app-level overlap checks, or use native Postgres ranges with exclusion constraints. The package is a candidate implementation of the latter; the decision itself should be made on correctness and query performance, not on this library.
• Data-integrity roadmap. Postgres daterange plus a EXCLUDE USING gist constraint is the cleanest way to make double-booking structurally impossible. If "we occasionally double-book" is a known support pain point, this is the lever — and it justifies a small, deliberate investment rather than an ad-hoc fix.
• Reference implementation, not a dependency. With 1 star, 0 dependents, and a low opportunity score (~15.4), treat the repo as a readable example of writing Doctrine DBAL custom types and Symfony bundle wiring. It informs the design of an in-house type, not a procurement decision.
• Vendor/dependency policy review. Adopting a single-maintainer bundle published by a web studio (Sprint-F.RU) with no downstream consumers is a supply-chain and bus-factor question that should go through whatever dependency-review process you have — the answer is likely "no" for anything customer-facing.
• Stack-scoping conversations. Its existence confirms a real gap: Doctrine does not give you first-class Postgres range types out of the box. If the roadmap includes interval-heavy features, budget for a Doctrine type layer regardless of which package you pick.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony + Doctrine ORM + PostgreSQL and have no plans to abstract the database.
• You specifically need daterange (or date/datetime mapping quirks) as a first-class entity field, typically to pair with GiST exclusion constraints.
• You are willing to fork it into your own vendor namespace and own the maintenance, tests, and PHP/Doctrine version upgrades.
• Your use case is internal or low-risk, and a review of the source (it is small and MIT-licensed) has been completed by an engineer.
• You can verify compatibility with your Doctrine DBAL/ORM and PHP versions — a 1-star bundle almost certainly has not been tested against current Doctrine 3.x/4.x or PHP 8.3+.

Look elsewhere — or build — if any of these apply:

• Any non-Postgres database is in play, now or on the roadmap.
• You need broader Postgres type coverage (tsrange, tstzrange, int4range, numrange, multiranges, arrays, JSONB, citext). Prefer a maintained library such as martin-georgiev/postgresql-for-doctrine, or Doctrine's own custom-type mechanism.
• Community support, security patching, or SLA is a requirement. 0 dependents and 1 star means no ecosystem validation and no evidence of ongoing maintenance.
• Your organization has supply-chain, sanctions, or data-residency review requirements that a small, single-vendor Russian-studio package would need to clear.
• The feature is not on the roadmap. Do not adopt infrastructure for a hypothetical.
• A plain pair of date columns plus an application-level constraint already satisfies the requirement at your scale. Ranges are worth it when you need exclusion constraints or range operators in SQL — otherwise they add cognitive overhead.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a small open-source Symfony add-on that lets our database enforce date-range rules — for example, preventing two bookings from overlapping on the same resource. The underlying idea is sound and directly supports scheduling and subscription features. The package itself, however, has essentially no adoption and a single maintainer, so I do not recommend taking it as a dependency. Recommendation: spend roughly one to two engineering days writing a small in-house equivalent, or adopt a well-maintained Postgres-types library. Cost is negligible either way; the payoff is that double-booking becomes structurally impossible rather than a bug we fix after the fact.

For engineering: The repo is a thin Symfony bundle registering Doctrine DBAL custom types for Postgres date, datetime, and daterange. It is MIT-licensed and small enough to read in an afternoon, which makes it a useful reference for the type-conversion and bundle-registration pattern. It is not a safe dependency: one star, zero dependents, unclear Doctrine 3/4 and PHP 8.x support, and no visible maintenance cadence. Proposal: use it as a design reference and vendor a minimal daterange type plus a GiST exclusion migration into our own codebase, where we control the upgrade path. If we'd rather not own it, martin-georgiev/postgresql-for-doctrine covers this and more with real community backing — that's the option I'd put in front of architecture review alongside the build estimate.

Ask: Approve a timeboxed spike (1–2 days) to prototype the daterange + exclusion-constraint path on a non-critical table, and defer the build-vs-adopt decision until we have a working migration and a query benchmark.