I've seen Unix timestamps used in APIs but I've always used ISO UTC datetimes because I like they are readable both by humans and machines easily.
Think about the various transformations inwards and outwards. An API will likely accept time as a string in input (especially if you need to know the timezone of the caller), the language with which the app is built in will likely easily parse both formats (and since you're a human you'll use operators to manipulate time that deal with something more "chatty" than just seconds since epoch). If the app is backed by a relational DB that date you parsed in input will probably land in a "datetime with timezone" column or something like that. So you have strings and datetime types all the way in input.
You're left with a decision of how to present the output, if there's not much difference in performance I'd either use the ISO string or... both :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've seen Unix timestamps used in APIs but I've always used ISO UTC datetimes because I like they are readable both by humans and machines easily.
Think about the various transformations inwards and outwards. An API will likely accept time as a string in input (especially if you need to know the timezone of the caller), the language with which the app is built in will likely easily parse both formats (and since you're a human you'll use operators to manipulate time that deal with something more "chatty" than just seconds since epoch). If the app is backed by a relational DB that date you parsed in input will probably land in a "datetime with timezone" column or something like that. So you have strings and datetime types all the way in input.
You're left with a decision of how to present the output, if there's not much difference in performance I'd either use the ISO string or... both :)