Common Bundle Laravel Package

Product Decisions This Supports

The real scope is one class, not a framework. This is a Symfony bundle whose documented capability is a single Doctrine DBAL type (UTCDateTimeType) that forces all datetime columns to be read/written as UTC. Everything else in the repo is packaging. That reframes the decision from "adopt a common utilities bundle" to "decide our timestamp storage convention, and whether we write 20 lines or inherit a dependency."

Decisions this evaluation actually informs:

• Timezone persistence convention. The single most valuable decision here is organizational, not technical: do we normalize all persisted timestamps to UTC at the ORM boundary? Yes — this is the correct default for any product with more than one timezone, and it eliminates a whole class of DST and reporting bugs before they reach customers. The package is just one implementation of that decision.
• Build vs. buy. The "buy" side is thin. The package is 0 stars, 0 dependents, last released 2020-11-05, and its CI badge points at Travis (defunct). There is no maintainer surface, no security response path, and no community to absorb breakage. For a ~20-line type class that reproduces a well-known Doctrine recipe, build wins decisively.
• Dependency policy precedent. Adopting this sets a precedent that we take on unmaintained, single-author, zero-adoption packages for trivial functionality. That is a governance decision with compounding cost across a codebase, and it matters more than this package's own footprint.
• Roadmap risk, not feature risk. Doctrine DBAL 3 changed the DateTimeType conversion signatures (platform argument, nullable return types). A 2020-era type is a plausible upgrade blocker for any DBAL 3 migration — i.e., this dependency can become the reason a platform upgrade stalls. Verify against our DBAL version before it enters a critical path.
• Existing-usage triage. If this is already in a codebase, the decision is a scheduled replacement, not a review. The blast radius is small by design, which makes it a cheap cleanup win to sequence into an ordinary maintenance sprint.

When to Consider This Package

Consider it only if all of the following hold:

• You are on a Symfony application (this is a bundle with Symfony DI/config conventions — it is not a Laravel package and offers no service provider, facade, or Laravel-idiomatic integration) and already accept bundle-style dependencies.
• You are on a legacy Doctrine DBAL 2.x stack and need UTC-normalized datetime handling today with zero implementation time.
• You have a pinned, locked dependency tree where transitive churn is not a concern and no DBAL upgrade is on the near-term roadmap.
• The alternative cost genuinely exceeds the risk — i.e., a team with no bandwidth to write and test a type class, on a codebase with no future.

Look elsewhere — which is the recommendation — when any of these apply:

• You are on Laravel. This package's premise does not fit. Laravel's own idiom is config/app.php timezone plus casting/accessor conventions, or a small custom Cast. A Symfony bundle is the wrong shape for the problem.
• You are starting anything new. Copy the pattern into your own codebase as a first-party type. The logic is small, testable in an afternoon, and you own the upgrade path.
• You need Doctrine DBAL 3+. Assume incompatibility until proven otherwise; the conversion API changed.
• You need the package to do more than one thing. The description ("Common tools/libs") promises breadth; the README delivers one type. There is no evidence of a broader utility set worth adopting, so there is no bundle-level leverage — only a single-class dependency.
• Maintenance and security posture matter (they should, for anything in a payment, auth, or audit path). Zero maintainers, zero dependents, four-plus years since release is a fail on any reasonable dependency policy.
• You are evaluating this as a candidate for replacement or fork. Forking is defensible only if you intend to own and publish the type internally; at that point, just write it internally.

Adoption verdict: reject as a dependency; adopt the underlying idea natively. Implement UTC-at-the-boundary internally, add a test asserting round-trip behavior across DST boundaries, and encode the convention in a written standard so no team reintroduces local-time storage by accident.

How to Pitch It (Stakeholders)

For executives — one line: This package encodes a genuinely good practice (store timestamps in UTC) in a fragile wrapper — zero users, no maintainer, last shipped in 2020 — so we should adopt the practice and skip the dependency.

For engineering — the substance: The package's only documented feature is a Doctrine UTCDateTimeType that forces datetime columns to persist as UTC. That is the right convention and worth standardizing. But we can reproduce it as a first-party type in well under a day, with tests we control, no Symfony-bundle coupling, and no exposure to the DBAL 3 signature change that a 2020-era type is likely to block. The repo shows 0 stars, 0 dependents, and no activity since November 2020 — there is no support contract, no security response, and no community to catch regressions.

The tradeoff in plain terms: Build cost is roughly one engineer-day, once. Buy cost is a permanent, unmaintained dependency in the persistence layer plus a likely blocker on our next Doctrine upgrade. The build is cheaper on both axes.

What I'm asking for: Approval to (1) standardize UTC-at-the-ORM-boundary as our timestamp convention, and (2) implement it internally rather than via elcweb/common-bundle. If the package is already present somewhere in our stack, I want it on the maintenance backlog for replacement with the internal type in the next routine sprint — small blast radius, cheap fix, removes a known dead dependency from the critical path.