Comments (9)
Hi,
LocalDateTime
represents a different concept from ZonedDateTime
and PHP's DateTimeInterface
: a date and time without a time-zone; so it makes no sense to extend DateTimeImmutable
.
This is precisely what I dislike in PHP's implementation: a single class is used to represent many concepts (local date, local time, local date-time, date-time with a time zone, ...)
As for ZonedDateTime
, extending DateTimeImmutable
would create more problems than it solves, as ZonedDateTime
would suddenly inherit from methods that return a DateTimeImmutable
, which is very confusing, and some methods would conflict, such as getTimeZone()
.
For interoperability, what's necessary is a fromDateTime() and a toDateTime()
method. The former is already implemented, while the latter is not.
I'm leaving this issue open until toDateTime()
is implemented!
from date-time.
Consensus always wins, I guess! 😉
Added in 91a0c9c and released in 0.1.8.
from date-time.
The main problem with DateTimeImmutable is absence of easy way to convert it to DateTime (many libs still expect this type).
from date-time.
I agree, I think that interoperability with native PHP date classes is worth the method.
from date-time.
Fixed in 052c9d7 and released in version 0.1.6:
New method:
ZonedDateTime::toDateTime()
: converts theZonedDateTime
to a nativeDateTime
object.
Note that I hesitated to add a toDateTimeImmutable()
method as well, but because it's trivial, I think we should leave this to the user:
$dateTime = $zonedDateTime->toDateTime();
$dateTimeImmutable = \DateTimeImmutable::createFromMutable($dateTime);
from date-time.
Why not return DateTimeImmutable
in method toDateTime()
? As DateTime
is broken implementation. It mutable value object. I do not see any point in using DateTime
class for anything.
from date-time.
Good question, I guess the choice I made was purely because of the naming: toDateTime()
would return a DateTime
.
I pretty much never use PHP's DateTime classes myself, so I'm not sure which of DateTime
and DateTimeImmutable
people use most and what they would expect here.
This can be changed in 0.9 if needed, but I'd love to hear other people's opinion here.
from date-time.
Note that PHP 7.3 added a DateTime::createFromImmutable()
factory method (not documented yet), but this is not relevant anyway as brick/datetime targets PHP 7.1 at the moment.
@solodkiy makes a good point here, and it makes sense to keep the DateTime
return type IMO.
Should we add toDateTimeImmutable()
methods then? I still think that it clutters the API with methods that just call DateTimeImmutable::createFromMutable()
.
Let me know what you think.
from date-time.
I still think that it clutters the API with methods that just call DateTimeImmutable::createFromMutable().
Yep, it is definitely hard to read and it is quite common use-case. It makes sense to me to implemented also toDateTimeImmutable()
as it is something cheap to do and makes it easy to cooperated with other PHP code (e.g. template filters, etc.)
from date-time.
Related Issues (20)
- Discussion: ISO8601/RFC3339 time + timezone class HOT 1
- ZonedDateTime::{plus,minus}{Minutes,Hours,Seconds} behaves differently to Java 8 HOT 2
- Instant::toISOString() is not RFC 3339 compliant HOT 2
- Add LocalDateRange::toPeriod HOT 4
- Named Constructors for TimeZone HOT 2
- isEqualTo(TimeZone::utc()) is not normalized HOT 7
- `Interval` is so barebones compared to `LocalDateRange`
- Add Seconds value object HOT 3
- Interface for any object representing an interval of time HOT 8
- Some objects with ISO representations are missing a parse method
- LocalDateRange / endExclusive HOT 6
- Negative Duration HOT 2
- `null`-friendly methods HOT 13
- [performance] Optimizing LocalDate::plusDays() method HOT 1
- Performance optimization: skip validation when creating objects (SOLUTION: use Reflection) HOT 8
- Broken badge on README HOT 2
- Year::toISOString() not conformation to ISO 8601 HOT 2
- Add `DefaultClock::travelForwards(Duration)` HOT 4
- `LocalDate::parse(...)` does not recognise ISO-8601 HOT 1
- Year::atMonth() should accept a Month HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from date-time.