Requirements

There are three basic requirements we have with respect to dates, times and duration:

Current situation

In most places, the above classes refer to types ISO8601_DATE, etc (now slightly renamed to Iso8601_date etc), which were defined as interface-only classes to be inherited. In AOM2, the C_DATE etc classes referred to 'Date', etc.

DV_DATE, DV_TIME etc supplied their own value: String field, which is formatted according to the ISO8601 standard. So the model of DV_DATE etc is not quite right - they inherit from ISO8601 but supply their own String field.

Separately, the various programming languages have very varied ideas of 'Date', 'Time', 'Duration' etc.

To date, we have two areas of legacy that I can see:

Proposals

Original Proposal (TB)

See original email: essentially:

Proposal (Bjorn +/- Pablo)

Bjorn:

This would result in just one set of primitive types Date, Time, Date_time and Duration, which I agree would be nicer. My understanding is that you are saying that Date.value, which is a native value - will be different in Java, C#, Python etc - is the value field of Date (via Temporal). But maybe you are saying that this is actually the String field, i.e. the field that we already use.

If that is the case, this is really just saying that what is called Iso8601_date in the other models (RM, AOM, TP) should be renamed to 'Date', and that in the Foundation types, we should collapse the triple types IDate/Date/Iso8601_date to just 'Date', which has a single value: String field inherited from Temporal. (confirmed by Bjørn Næss @ DIPS)

Response by TB

If the above is true,  I like it, it is nice and simple, but:

Pablo had a few other things to say, I think we will discuss some separately (AOM2 fix for example).

Final Proposal

Collapse each set of class triples (i.e. IDate, Date and Iso8601_date etc) into just a single class named Date, etc, that has a String field and all the interface of IDate + Iso8601_date and so on.

Responses by Back-end Implementers