Nice idea, but seems to lack timezone awareness, which puts me off completely. Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs! If you're pushing events to people, presumably you know exactly when they're goi…
Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.
9.00 PM is very clear to mean 21.00 in 24H format. What isn't clear is if 9.00 is 12H or 24H format. 9.00 AM or 9.00 PM is. However if you may reasonably assume the user uses 24H format, it is clear. It always takes up less space to use 24H format, though 12H format is always clear. Except for TZ (timezone), both all time suffers from that.
[EDIT]Oops I messed up, and that's why I dislike these and prefer ISO8601. Although one nice thing about DD/MM/YYYY is that its little endian (which is easy to remember for laymen as going from small to big). Keeping rest of comment as is.[/EDIT]