Weave Code
Datetime Laravel Package
fresh/datetime
Fresh DateTime adds convenient, expressive date and time handling to Laravel and PHP applications. It simplifies parsing, formatting, comparing, and manipulating dates, with timezone-aware helpers and a clean, chainable API for everyday scheduling and timestamp tasks.
🐘 🕒 📅 PHP library that provides additional functions for processing dates & times.
Frequently asked questions about Datetime
- How do I install fresh/datetime in a Laravel application?
- Install it with composer require fresh/datetime. There is no service provider, no publishable configuration, and no migrations, so adoption is just a dependency and autoloading. That makes a spike cheap, but it also means nothing in the framework enforces usage conventions for you.
- Does fresh/datetime replace Carbon in Laravel?
- No. Laravel already ships Illuminate\Support\Carbon in every installation, and Carbon covers most everyday helpers such as isWeekend, isPast, startOfWeek, and diff methods. fresh/datetime is a second, parallel date abstraction, so the real question is whether its incremental helpers justify the which-one-do-I-use ambiguity.
- Is fresh/datetime timezone-aware?
- Yes. The package advertises timezone-aware parsing and conversion, which is one of its main selling points over hand-rolled date code. The caveat is timezone-less input: confirm whether helpers fall back to date_default_timezone_get() and make that behavior explicit in your own wrapper. Pin application and database timezones in tests so conversions cannot silently drift.
- Can I use fresh/datetime without Laravel, in plain PHP?
- Yes. The package is framework-agnostic, working on date and time values with no container bindings, no service provider, and no runtime side effects. You can install it in a plain Composer project, a CLI tool, or a Laravel app without code changes. That also means it will neither block nor ease a Laravel upgrade.
- Which PHP and Laravel versions does fresh/datetime support?
- The package has no framework version coupling. The technical evaluation found it compatible in principle with Laravel 10, 11, and 12 on PHP 8.1+, but you should confirm the actual require.php and Carbon constraints in composer.json before adopting. If your runtime is PHP 8.3 or 8.4, verify those versions are tested rather than assumed.
- Does fresh/datetime handle DST, leap years, and ISO-8601 week boundaries?
- The overview does not document DST, leap-year, or week-boundary behavior, and date bugs of this kind fail silently in reports rather than throwing exceptions. The codebase is small enough to audit fully, so read the source and add tests that pin DST transitions, locale-dependent first-day-of-week, and year-end week numbering. If upstream has no CI matrix covering those cases, treat that as a gap you must close yourself.
- Is fresh/datetime safe and maintained enough for production?
- Operationally the risk is low: it is stateless date arithmetic with no I/O and essentially no attack surface. The real risk is confidence: a single maintainer, roughly 18 stars, and no dependents means no evidence of production use at scale and no ecosystem pressure to keep it current. If that matters to your team, vendor the useful helpers into your own code under the MIT license instead of depending on it.
- How do I test code that uses fresh/datetime?
- Because there are no container bindings, you can test it directly without mocking. Freeze or inject the current time in your own code, then assert results across DST change dates, month and year boundaries, and leap days. Keep a small fixture suite that runs in a non-UTC timezone so locale and offset assumptions surface early.
- How does fresh/datetime compare to Carbon and other date libraries?
- Carbon is Laravel's default and already handles most everyday helpers, so the honest comparison is a function-by-function gap list. If fresh/datetime adds fewer than about five genuinely useful functions, copy that logic into an internal App\Support helper with attribution. If its surface is larger, adopt it behind a single facade so the rest of the codebase has exactly one date API.
- Should I standardize on fresh/datetime or Carbon in a large codebase?
- Standardize on Carbon, which Laravel's casts, model timestamps, and now() already use, unless a written gap analysis proves fresh/datetime earns its place. A parallel helper API creates a review burden, because every date call becomes a style question. If you do adopt it, confine it to one internal facade or adapter and forbid direct use elsewhere.
Weaver
How can I help you explore Laravel packages today?