Start dates, end dates, start datetimes and end datetimes

Deals provide the terms and conditions under which a Release can be offered to consumers. These include the points in time from when, and until when, a given Release may be made available. DDEX standards offer a series of fields to communicate these in the DetailedDeal composite:

  • The overall validity period (start and end date): ValidityPeriod

  • The day from which the Release may be shown to consumers: ReleaseDisplayStartDate

  • The day from which the track listing may be shown to consumers: TrackListingPreviewStartDate

  • The day from which the cover art may be shown to consumers: CoverArtPreviewStartDate

  • The day from which a clip of the Release may be shown to consumers: ClipPreviewStartDate

  • The day from which the Release would be available for pre-orders: PreOrderPreviewDate

It is also possible to communicate date-times instead of times. Such date-times can have two or three aspects: a date, a point in time on that date and, as an optional aspect, the time zone in which the time is given.

For example:

  • 2015-12-01 represents 1st December 2015

  • 2015-12-01T09:30:00 represents 9:30am local time on 1st December 2015

  • 2015-12-01T09:30:00Z represents 9:30am GMT/UTC on 1st December 2015

  • 2015-12-01T09:30:00-08:00 represents 9:30am PST on 1st December 2015

Handling Time Zones

When applying such information, especially in Deals that cover multiple time zones (whether in one territory or in multiple territories), three cases should be differentiated:

  1. A Deal with a start date of 2015-12-01 and an end date of 2015-12-31 for the US and UK would be available in both territories between 0:01 local time on 1st December until 23:59 local time on 31st December. Thus a consumer in London or Edinburgh would get access five hours before a consumer in Boston. Equally, (s)he would lose access five hours earlier.

  2. A Deal with a start date-time of 2015-12-01T09:30:00 and an end date-time of 2015-12-31T09:30:00 for the US and UK would be available in both territories between 9:30 local time on 1st December until 9:30 local time on 31st December. Thus a consumer in London or Edinburgh would get access five hours before a consumer in Boston. Equally, (s)he would lose access five hours earlier.

  3. A Deal with a start date-time of 2015-12-01T09:30:00-07:00 and an end date-time of 2015-12-31T09:30:00-07:00 for the US and UK would mean that consumers in both territories would get access to the Release at the very same point in time, regardless of their location. So the UK resident would get access at 16:30 and a New York resident at 7:30 in the morning.

Clearly approach number one is the simplest and is preferred if no specific time information is needed.

Global Deals

Should a Deal apply to the entire world (i.e. the TerritoryCode element is set to Worldwide) the same logic applies:

  1. A worldwide Deal with a start date of 2015-12-01 and an end date of 2015-12-31 would be available each territory between 0:01 local time on 1st December until 23:59 local time on 31st December.

  2. A worldwide Deal with a start date-time of 2015-12-01T09:30:00 and an end date-time of 2015-10-31T09:30:00 would be available in each territory between 9:30 local time on 1st December until 9:30 local time on 31st December.

  3. A worldwide Deal with a start date-time of 2015-12-01T09:30:00-07:00 and an end date-time of 2015-12-31T09:30:00-07:00 would mean that consumers in all territories would get access to the Release at the very same point in time, regardless of their location.

Should a Deal apply to the two territories such as Austria and the Cuba, the date or datetime would apply separately to each country. For example, a Deal with a start datetime of 2018-12-24T18:00:00 would come into effect in Austria when the clock strikes 6pm in Vienna and in Cuba when the clock strikes 6pm in Havanna (i.e. six hours later).

If, however, the datetime is provided with a time zone designator, deal would start at the same moment in time (i.e. earlier in the morning for Cuban customers).

Multiple Time Zones

In cases where a Deal covers multiple time zones in one territory it is also possible for sender and recipient to agree a single time zone that is used for all time zones in that territory.

One example where this approach is common is Russia where Deals are often communicated in Moscow time (MSK) for the entire country. A Deal starting, for example, at 09:00 MSK (09:00:00+03:00) would become available for a user in far-Eastern Siberia at 21:00 Kamchatka Time (PETT) and a user in Kaliningrad would see the Deal become available at 08:00 Kaliningrad Time (KALT). 

ERN-3 as well as ERN-4 contains a number of fields that can communicate dates or date-times. Some of these are to communicate “historic” information: when was “Hey Jude” recorded? When was it released? These fields are typically dates and support a variety of flags to indicate precision (e.g. IsBeforeand IsApproximate).

Other dates/date-times have a direct legal consequence in the context of an ERN message: the start and end dates of the validity period of a commercial deal, for instance. 

These periods can currently be provided in several forms:

  • Just a start date;

  • Just an end date (from ERN onwards 4.2 this will be impossible);;

  • A start and an end date;

  • Just a start date-time;

  • Just an end date-time (from ERN onwards 4.2 this will be impossible);; and

  • A start and an end date-time.(1)

DDEX has agreed to phase-out the “dates only” means of communicating such information over time. DDEX therefore recommends that implementers only use date-times.

(1) Note, it is technically also possible to have a period tag with no start and no end. This approach is, however, not acceptable; from ERN onwards 4.2 this will be impossible.

Search