Weave Code
Code Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Datetime Parts Laravel Package

digital-craftsman/datetime-parts

Value objects for precise date/time parts in PHP: Moment (UTC-based) plus Time, Date, Month, Year, Day/Weekday and collections. Avoid misleading DateTime comparisons, handle timezone-safe modifications across DST, with Symfony normalizers and Doctrine types.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture Fit

  • Precision-Oriented Design: The package excels in addressing a critical gap in PHP’s DateTime ecosystem by introducing granular, immutable value objects (Moment, Time, Date, Month, Year, Day, etc.). This aligns perfectly with domain-driven design (DDD) and clean architecture principles, where domain-specific abstractions reduce ambiguity and improve maintainability.
  • UTC-Centric Workflow: The forced UTC storage for Moment objects (with timezone-aware modifications) mitigates DST and timezone-related bugs—a common pain point in distributed systems. This is particularly valuable for global applications or microservices where consistency is paramount.
  • Symfony/Doctrine Integration: The bundle’s seamless integration with Symfony’s normalizers and Doctrine types enables direct usage in entities, APIs, and serialization layers without boilerplate. This reduces coupling and simplifies data persistence.
  • Immutability: Immutable value objects prevent side effects, making the codebase more predictable and thread-safe. This is ideal for concurrent environments (e.g., Laravel queues, real-time systems).

Integration Feasibility

  • Laravel Compatibility: While the package is a Symfony bundle, Laravel’s dependency injection (via illuminate/container) and Doctrine support (via laravel-doctrine) allow for partial adoption. Key challenges:
    • Symfony-Specific Features: The Clock component (for testing) and normalizers may require wrappers or custom implementations in Laravel.
    • Service Provider Setup: Laravel lacks Symfony’s bundle autoloading, so manual registration of Doctrine types and normalizers will be needed.
    • Testing: The FrozenClock for time-freezing tests aligns with Laravel’s Carbon testing utilities but may need adaptation.
  • Database Schema: Doctrine types for Moment, Date, etc., require database columns to match the package’s expectations (e.g., Moment needs a DATETIME(6) or TIMESTAMP(6) column). Migration tools like Laravel Migrations or Doctrine Migrations can handle this.
  • Legacy Code: Replacing DateTime with Moment/Time requires refactoring comparison logic (e.g., isBeforeInTimeZone instead of >, <). This is a breaking change but yields long-term clarity.

Technical Risk

  • Pre-1.0 Stability: The package is not yet at v1.0, with breaking changes between minor versions (e.g., PHP 8.1→8.2 drop, Symfony 6.3→7.0). Mitigation:
    • Pin to 0.14.* and monitor changelogs.
    • Isolate critical paths (e.g., use Moment only for new features).
  • Performance Overhead: Value objects add indirection over raw DateTime. Benchmark critical paths (e.g., bulk operations) to ensure acceptable latency.
  • Ecosystem Lock-In: Heavy reliance on this package (e.g., for all datetime logic) could complicate future migrations. Start with high-impact domains (e.g., scheduling, bookings).
  • Doctrine Quirks: The package’s Doctrine types may interact unpredictably with Laravel’s query builder or Eloquent. Test ORM operations (e.g., where, orderBy) thoroughly.

Key Questions

  1. Adoption Scope:
    • Should we adopt this package globally (replacing all DateTime instances) or incrementally (only for new features)?
    • Which domains (e.g., payments, calendars) would benefit most from precision?
  2. Testing Strategy:
    • How will we adapt FrozenClock for Laravel’s testing environment (e.g., Carbon mocking)?
    • Should we create a Laravel-specific wrapper for the Clock interface?
  3. Database Compatibility:
    • Are our existing DATETIME/TIMESTAMP columns compatible with the package’s requirements (e.g., microsecond precision)?
    • How will we handle legacy data migrations?
  4. Performance:
    • What is the overhead of Moment vs. Carbon/DateTime in our most frequent operations (e.g., API requests, background jobs)?
  5. Team Buy-In:
    • How will we train developers on the new abstractions (e.g., Time vs. Moment) to avoid misuse?
    • Should we create a style guide or coding standard for datetime usage?

Integration Approach

Stack Fit

  • Laravel Core:
    • Replacement for Carbon/DateTime: The package can serve as a drop-in replacement for Laravel’s Carbon (which extends DateTime) in domains requiring precision. Use Moment for timestamps and Time/Date for granular comparisons.
    • Service Container: Register the package’s services (e.g., Clock) in Laravel’s container. Example:
      $this->app->bind(\DigitalCraftsman\DateTimePrecision\Clock::class, \DigitalCraftsman\DateTimePrecision\SystemClock::class);
      
    • Facades/Helpers: Create Laravel-specific helpers (e.g., now() returning a Moment) to ease adoption.
  • Symfony Dependencies:
    • Normalizers: The package relies on digital-craftsman/self-aware-normalizers. Install this separately and configure Laravel’s serializer (e.g., via symfony/serializer) to use the provided normalizers.
    • Doctrine: Use laravel-doctrine/orm to integrate Doctrine types. Ensure the package’s types are auto-registered in Doctrine’s configuration.
  • API Layer:
    • Leverage Symfony’s normalizers for API responses (e.g., JSON serialization). For Laravel APIs, use the serializer package or manually normalize objects.

Migration Path

  1. Phase 1: Proof of Concept
    • Isolate a high-impact feature (e.g., appointment scheduling) and replace DateTime/Carbon with Moment/Time.
    • Test edge cases (e.g., DST transitions, timezone comparisons).
  2. Phase 2: Core Integration
    • Replace Carbon factories (e.g., now(), parse()) with Moment equivalents.
    • Update Doctrine entities to use the new types (generate migrations for schema changes).
    • Adapt queries to use the package’s comparison methods (e.g., isBeforeInTimeZone).
  3. Phase 3: Full Adoption
    • Replace remaining DateTime usages with value objects.
    • Deprecate legacy datetime helpers in favor of the package’s API.
    • Update CI/CD pipelines to test with the new package (e.g., timezone edge cases).

Compatibility

  • Laravel-Specific Tools:
    • Eloquent: The package’s Doctrine types may not work directly with Eloquent. Use raw Doctrine entities or create a hybrid approach (e.g., store Moment as JSON in a text column).
    • Queues/Jobs: Ensure Moment serialization works in Laravel’s queue system (e.g., Redis, database). Test job persistence and deserialization.
    • Carbon Extensions: Some Laravel packages (e.g., spatie/laravel-activitylog) rely on Carbon methods. Abstract these behind adapters or fork packages as needed.
  • Third-Party Packages:
    • Audit dependencies for DateTime usage. Prioritize packages with clear interfaces (e.g., dependency injection) for easy adaptation.
    • Example: Replace Carbon in spatie/laravel-permission by injecting a Clock interface.

Sequencing

  1. Database Schema:
    • First, update the schema to support the package’s types (e.g., DATETIME(6) for Moment). Use Laravel Migrations or Doctrine Migrations.
  2. Domain Layer:
    • Refactor domain models (e.g., Appointment, Booking) to use Moment/Date types.
  3. Application Layer:
    • Update services/repositories to use the new types and their methods.
  4. API Layer:
    • Configure normalizers for API responses. Test serialization/deserialization.
  5. Testing:
    • Replace Carbon test helpers with FrozenClock. Update snapshot tests for datetime formats.
  6. Deployment:
    • Roll out in stages (e.g., feature flags for new datetime logic).

Operational Impact

Maintenance

  • Pros:
    • Reduced Bugs: Immutable value objects and explicit comparisons (e.g., isBeforeInTimeZone) minimize timezone/DST issues.
    • Self-Documenting Code: Methods like modifyInTimeZone make intent clearer than manual DateTime arithmetic.
    • Testing: The Clock interface and FrozenClock simplify time-freezing tests, reducing flakiness.
  • Cons:
    • Dependency Management: Pinning to 0.14.* requires monitoring for breaking changes. Plan for periodic upgrades.
    • Debugging: Stack traces may include package internals, complicating error diagnosis. Consider logging Moment operations for observability.
    • Tooling: IDE support (e.g., autocompletion) may lag for new classes (Day, Days). Document usage patterns.

Support

  • Developer Onboarding:
    • Create a cheat sheet for common operations (
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
terminal42/code-quality-tools
codifyo/ts-generator-bundle
andydefer/laravel-cluster
testo/fiber
mintobit/jobqueue
a4sex/maintenance-bundle
a4sex/entity-date-update
a4sex/client-identifier
a4sex/base-utilites
a4sex/key-value-storage
a4sex/micro-status
chilldev/dependency-injection-extra
datinglibre/datinglibre-app-api
biberltd/corebundle
bricre/symfony-bundle-test
biberltd/logbundle
dominium/http-adapter-bundle
dominium/google-analytics
a4sex/auto-clean-entity
christhompsontldr/laravel-inky