Mark Story

That seems like a better scale than what we have now.

> Should the docblocks for these shared properties be moved down to ChronosInterface? The properties aren't part of the interface, so I'm not sure they should be moved down.

Those properties come from the `__get` implementation in the `MagicPropertyTrait`.

The main goal with the ChronosInterface was to allow separation between native DateTime objects and enriched ones like @josegonzalez mentioned. I can see how the current interface hints don't allow...

I think that interface breakdown makes sense. I was thinking more about interfaces for immutable/mutable differences earlier today, and I'm not sure it makes sense to have them. Even in...

@nyamsprod The intention/goal of `Date` was to provide the familiar `DateTime` interface but constrain the valid set of values to calendar dates. I wanted to keep as much compatibility as...

A Time with a timezone might be pretty confusing. How would you represent day rollovers? For example 2pm EST converted to JST? What kind of methods would you envision being...

We might be able to implement [DateTimeInterface](http://php.net/datetimeinterface) but I'm not sure all the mutation methods that `DateTime` and `Chronos` offer would make sense.

It could be useful when mapping `time` columns. We currently map those to `Cake\I18n\FrozenTime` subclasses so maintaining backwards compatibility might be tricky unless we implement the very wide `ChronosInterface`.

@martinbean That sounds like an interesting scenario. I'm not sure it fits along the `DateTimeInterface` though, which leads me believe we want something _else_.