Behaviour where posted transactions only have an associated date.

[WestpacOpenBanking]

Description

Currently postingDateTime in BankingTransaction has a type of DateTimeString. Frequently, only the date of posting is recorded without an associated time. Data recipients are likely to treat those transactions as if they occurred at a certain time in a certain time zone with the same date. However, this choice is arbitrary with many possible choices. This issue is particularly problematic in relation to the filtration of results from Get Transaction For Account endpoint using the oldest-time and newest-time query parameters – unexpected behaviour may occur if Data Recipients filter based on date and time (transactions that appear to be from the wrong day, for instance).

Area Affected

The primary field which is affected is postingDateTime in BankingTransaction. There may be similar issues with valueDateTime and executionDateTime, or in other cases where the DateTimeString is used (especially in conjunction with filtration).

Change Proposed

We recommend that the standard specify that posted transactions that only have a recorded date and not an associated time should be deemed to have occurred at a certain time e.g. 2:00 am AEST on the same day). This change would likely need to be future dated as different data holders may have already implemented inconsistently.

[perlboy]

DateTimeString includes a time zone so recipients will treat it according to the timezone it is presented in. This aside, it does seem valid to at least clarify what the "default time if not available" value should be especially since the description is This is the time that appears on a standard statement which, as far as I'm aware, zero banks print times on their "standard statements".

Normal convention would be 0:00 UTC (ie. epoch at the first second of the day) although I accept there's no specific "standard" to this.

[nils-work]

For reference, timezone-related concerns have also been raised in #539, and explored in relation to energy endpoint date filtering in the last block of this comment.

[nils-work]

As this issue could be relevant to changes being considered in MI19 (#636), is it still a valid concern?