Improve TypedData date handling [#1867888]

At #1778178: Convert comments to the new Entity Field API it turned out that the current date handling of the typed data API is sub-optimal. Creating DateTime instances is costly, so it needs to be well-thought. Also, it's a bit strange to have $typed_data wrapping another object - the DateTime object, so you end up with code like $comment->created->value->getTimestamp(). Then the storage has to take care of properly mapping the date value back to the storage format, thus it requires additional metdata.

Because of that #1778178: Convert comments to the new Entity Field API does not implement proper date fields yet, but defines the timestamps as simple integer_item fields.

Let's re-think possible options here and fix the implementation.

Comments

Comment #1

fago

German

Vienna

CreditAttribution: fago commented 16 December 2012 at 15:43

I think it might be a good idea to use a similar appraoch as we do for complex data and lists for dates and durations. Thus, have a "DateInterface" and a "DurationInterface" and register data types like DateTimestamp and DateISO which hold the primitive string or integer as value, but implement the interface. That way, processing fields at the storage level stays simple while code can leverage dates independently from the chosen representation format based upon the interface.

As an option, we could have DateTimestamp inherit from DateTime but invoke the parent construction only once the objects features are needed (to be benchmarked) - or as an alternative just instantiate the object internally and delegate the exposed API to it.

I.e., $comment->created->value would just remain the timestamp, but $comment->created->get('value') would give you the typed data object implementing the DateInterface.