Please consider the restoration of DateTime (without offset)

In odata_1396.ezm (odata digest message), I noted:

Accepted: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/47764/latest/odata-meeting-19_on-20121220-minutes.html
was:
-Remove Edm.DateTime (with no offset).
...

I am sorry that I was unable to join conference calls to discuss this before it was voted on, but the calls are a little early in the day for me to attend.

In various other discussions in the ODATA issues list, I think that we established that sometimes it may makes more sense for an object to have a separate field containing time zone name or offset, e.g. see xCal specification section 4.3.5 (http://tools.ietf.org/html/rfc5545#section-3.3.5) has DATE-TIME without offset, and a separate field type of UTC OFFSET for the offset (in OData this could easily be stored as a "short" number of minutes, I am not going to propose a separate OData type for UTC offset).

I cannot see a strong rationale for eliminating DateTime (without offset) while adding Date (without offset) and TimeOfDay (without offset). To be clear, I do not mean to suggest eliminating zoneless Date and TimeOfDay.

It seems reasonable to expect to be able to encapsulate xCal data in OData, without having to map multiple xCal fields (e.g. of types DATE-TIME and UTC OFFSET) into a single OData type (e.g. of type DateTimeOffset).

Also, bear in mind the enormous number of systems where backend data (with DateTime fields having no offset) may be exposed via OData, not because they are to be "published to the web for the whole world to see and therefore should be zoned", but just because OData is the "flavour of the day" for integrating backends with newly developed front-end applications. Forcing developers to reinterpret zoneless DateTime data as zoned, as opposed to leaving it unzoned with explicit (or implicit) separate fields indicating zone name or offset, seems rather extreme. We can encourage developers to use DateTimeOffset where appropriate, but without being heavy-handed and eliminating zoneless DateTime.