Time precision of Recurring Application Charge billing_on, activated_on, trial_ends_on fields

[beepbopboop]

Hi all,

Contrary to the latest documentation, which states that `billing_on`, `activated_on` and `trial_ends_on` fields are all "The date and time (ISO 8601 format)", testing of the API reveals that these values are returned as Date strings in format 'YYYY-MM-DD' (no "and time" here). I'm guessing that this may be the case for `cancelled_on` too, but haven't been able to test that path yet.

However, the `created_at` and `updated_at` fields are returned in ISO-8601 date and time format in UTC.

My questions:

1. Should it be expected that these date fields are always equivalent to e.g. 2020-08-25T00:00:00Z (midnight UTC) if returned as 2020-08-25 or are they specific to the user's timezone that accepted, uninstalled, etc. (hence unavailable via the API)? EDIT: it seems that the midnight UTC assumption can't possibly be the case for activated_on, cancelled_on since IIUC those are dictated by user interaction.

2. Are there any plans to provide ISO-8601 date and time values for these fields in the same format as are provided for `created_at` and `updated_at`?

Thank you.

[sillycube]

I also found that my billing_on date is in the format of 'YYYY-MM-DD'. 

Some data I found from an existing customer:

'billing_on': '2021-05-27', 'created_at': '2021-04-13T12:17:14+10:00', 'updated_at': '2021-04-27T14:02:24+10:00', 'test': None, 'activated_on': '2021-04-13', 'cancelled_on': None

Why are  the formats of these dates different?