Standardize a context type representing a range of time: TimeRange

[kriswest]

Enhancement Request (edited 6th May 2022)

Create a context type that can be used to represent a period of time.

Use Case:

Any user interfaces that represent or visualise events or activity over time can be filtered or focused on a particular time period, e.g.:

• A pricing chart
• A trade blotter
• An record of client contact/activity in a CRM

A time period may be closed (i.e. start and end date are both known) or open (i.e. only the start date is known, an end date will be known in the future, e.g. when an order is filled).

Example application in a raised intent:

User may want to view pricing/trades/customer activity for a security over a particular time period, the time range might be specified as the context for the ViewChart intent OR it be embedded in another context (e.g. a Chart context).

Example application as a broadcast context:

User filters a visualisation (e.g. a pricing chart) to show a particular period, the TimeRange is broadcast, other visualisations (e.g. a heatmap of activity by instrument, or industry sector etc.) receive it and filter themselves to show data over the same range.

Contexts

TimeRange

Represents a specific period of time.

Details

Property	Type	Required	Example Value
type	string	Yes	"fdc3.timeRange"
startTime	string *	Yes	"2022-03-30T15:44:44+00:00"
endTime	string *	No	"2022-04-30T23:59:59+00:00"

* The time should be encoded in the ISO 8601-1:2019 format with a timezone indicator included

Example

A closed range:

const timeRange = {
    type: "fdc3.timeRange",
    starttime: "2022-03-30T15:44:44+00:00",
    endtime: "2022-04-30T23:59:59+00:00"
}

An open range:

const timeRange = {
    type: "fdc3.timeRange",
    starttime: "2022-03-30T15:44:44+00:00"

Additional Information

The format of the strings representing times should refer to advice in the standard about formats, as proposed in: #645, with a note/link appearing in this context definition.

[hampshan]

Do we need to be more specific about whether the interval is open, closed, half-open, etc?

[kriswest]

@hampshan a colleague (@WatsonCIQ) pointed out to me that the endTime in this proposal is required, but in some examples we've already used it without (which I assume means an open interval?). It still seems valid for it to be an interval (TimeRange) if the end is currently unknown as that represents the fact that will have an end at some point.

I'll update to make endTime optional.

Whats a half-open interval/how would represent it?