Please clarify the meaning of filter functions applied to DateTimeOffset values

The accepted resolution for ODATA-122 seems to be at odds with protocol spec (2013-03-19) section 10.4.1.2 "Handling of DateTimeOffset Values", which now states:

Services SHOULD preserve the offset of Edm.DateTimeOffset values, if at all possible. However, where the underlying storage does not support offset services MAY be forced to normalize the value to some common time zone (i.e. UTC) in which case the result would be returned with that time zone offset.

Suppose I have a property "myTime" of type DateTimeOffset.

If I send a filter to the server (excuse the pseudo-filter syntax):

day(myTime) eq day(datetimeoffset'2013-03-21T16:59:44+13')

Now according to protocol spec 10.4.1.2, the server may adjust the RHS literal value to UTC (e.g. due to "storage" of the query expression fragments in memory, or in a database if the server so chooses). If the "day" function is then applied to the adjusted literal value, it won't give the same results as it would have if applied to the value without conversion to UTC.

If servers are allowed to adjust the offset in DateTimeOffset values to UTC (or another zone), then a client currently has no guarantee about the meaning of filter functions applied to the values.

—

Original issue text follows:
—

Consider for example the 'day' function applied to a DateTimeOffset.

Is this supposed to return the 'day' of the value when it is considered as UTC, or the 'day' component as it appears in the original literal value, which implies that the zone offset must be preserved when DateTimeOffset values are propagated?

If DateTimeOffset values are permitted to be 'normalized' by agents, but are not required to be, then the 'day' function applied to DateTimeOffset value would appear to be meaningless, unless it returns the UTC 'day'.