OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ubl-comment] DateTime - A Class Derivation


Title: DateTime - A Class Derivation

Comments from Bob Miller on OASIS Position Paper: Date and Time Expressions
Proposal 04, 28. June 2002

Good People,

We humans sure have a way of taking a simple thing like time and making it complex!

I've tried my best to reverse this human process, thus far to no avail.  I fostered adoption of Metric Time (in truth, I was just trying to get even with the Europeans for pushing a number of other metric measures at us.)

Just two of the many benefits of metric time:
1) Companies have wished their employees would work seven days a week;  employees have wished that every weekend was a three day weekend.  The metric week (ten days) can satisfy both wishes!

2) Seems everyone has wished for an extra hour in every day.  This one is a little bit tough, as days are divided into tens and hundreds of units.  But just to ease the conversion to metric time, we could define a 'metric' hour as four centidays, and presto, we have that extra hour in every day.

But I digress ...

In my opinion, there is need only for one conceptual representation for time, which measure consists of a start and end time (a range).  All these other expressions found in the position paper are derivable from the one measure:

Range:   A time range having a start point in time in some degree of precision, extended by nils to the maximum degree of precision supported, and an end point in time in the some degree of precision, extended by nines (in base 10) to the maximum degree of precision supported.

In formal terms, DateTimeRange is the base Class from which all other Date/Time measures are derived.  The DTR class defines properties startOfRange, endOfRange, maximumPrecision, precision, and formatType.  The DTR class defines processes to manipulate, store, encode, decode, import, and export values of the class.  Note that the behavior of DTR processes may be dependent on the class instance property values.

Subclasses of  the DTR class constrain properties of the class, and so affect the behavior of processes associated with the parent class. 

Consider two DTR instances, one of formatType "DateTime", and one of formatType Duration.  Consider also a DTR process invoked by Operator '+', such that the result of the operation was of format type DateTime.  Or consider two DTR instances, each of formatType Date, in which the overloaded '+' operator returns a DTR instance of formatType "Range"

A Duration can be represented by fixing startOfRange to zero.  DurationInSeconds can be represented by a subclass of Duration in which formatType="Seconds".

        
If this approach is adopted, a single consistent model for Date and Time Expressions is assured.  Yes, there is still a need to define the base DTR class, its properties, processes, and process behaviors.  And yes, there still is a need to define the sundry subclasses that simplify the use of the DTR class by 'fixing' or otherwise constraining properties of the parent class.

I am aware that at least one C++ Class library chose to implement Duration (TimeSpan) and Time (TimeInstant) as two distinct classes, and chose not to implement a TimeRange class.  This leads to the definition of more processes than the approach I suggest, though it is clearly viable, just as the approach taken in the position paper is clearly viable.  So I understand that the approach I suggest is but one of several viable approaches.  I just happen to feel that TimeSpan, TimeInstant, and TimeRange are closely related one to another, and the representation I recommend makes explicit that relationship through class hierarchy.

Cheers,
            Bob Miller



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC