Alexey Solodkiy
Alexey Solodkiy
Definitely don't want to see two different utc factory. Move `utc()` to `TimeZoneOffset` looks reasonable. Do we have any real use case for `TimeZoneRegion::utc()`?
This request if part of https://github.com/brick/date-time/issues/24 discussion. The main point is with it you could use it for properties, arguments and return types.
I got your point about UtcDateTime really is ZonedDateTime with a UTC timezone and made some try about it. It still work in progress but you can check the main...
Could we reopen this issue to attract some attention?
The main reasons I use extension against decoration is Liskov Substitution Principle. I use [fork](https://github.com/solodkiy/date-time/blob/master/src/UtcDateTime.php) of brick/date-time with this class (and some other improvements) in production and for now happy...
Still think that extending is better option here :)
> From a design perspective it makes no sense to have a TimeZone parameter to pass in UtcDateTime::now(), you shouldn't care about passing this value nor have the possibility to,...
> It basically corrupts class api and makes it confusing, just because it's trying to design a narrow UTCDateTime concept on the shoulder of a much broader ZonedDateTime concept. It...
Also we could add this method to YearMonthRange (looks reasonable), and Year, YearMonth, YearWeek (not so sure).
> YearMonthRange::getPeriod() would make sense, but not getDuration() as you cannot convert it to a number of days. Why not? YearMonthRange is inclusive. It include full first month, everything in...