Communicating deal dates

When a record company wants to make available a release to consumers via a DSP, they (or their distributor) would send a NewReleaseMessage to the DSP providing all the necessary metadata as well as a deal that contains the terms and conditions under which the DSP may make the release available to consumers.

One aspect of such a deal is its validity period. A validity period can come in four types:

• A start date and an end date;

• A start date but no end date;

• No start date but an end date; and

• Neither start nor end date.

Dates and datetimes

Dates themselves can come in two types: dates and datetimes. An example of the former is 6^th October 2023 (expressed in DDEX messages as 2023-10-06), an example of the latter is 15:56 Central European Time on the same day (2023-10-06 T15:56:00-01:00). See Wikipedia for more information. DDEX generally advises to use datetimes instead of dates in deals as they avoid issues such as the one discussed in this article.

Deals without start dates and end dates (or start datetimes and end datetimes)

The absence of a start or end date or datetime in a deal indicates that there is no limitation on the validity period. Thus, a deal with no start date would have been valid “since time immemorial” – in practice: from now on – and a deal with no end date means that the deal is valid “until eternity” – in practice: until the release is taken down via a later message.

Dates to send when communicating a deal (using dates only)

How to communicate a deal’s validity period depends on the situation. One main factor is whether a new deal – and its dates – need to be sent before the release has already been published. The table below lists the different cases:

(Other use cases, e.g where a new start date and a new end date are to be provided, can of course also be communicated by combinig the relevant table rows.)

The reason for using two days in the past in some of the cases addresses an issue with time zones: Differences in the time between a company in, say, Japan and a company in the US, could lead to releases inadvertendly being published or taken down. To avoid this companies are advised to add a margin of two days. 

Dates to send when communicating a deal (using datetimes)

Using datetimes the table becomes much simpler as the uncertainty around time zones is taken away and the datetime of message creation, which will necessarily be in the past when the recipient processes the message, can be used:

 Takedowns

The above tables enable a release to be taken down. The recommended way to take down a release is described here.