Epoch or iso8601 date format?

Unix/Epoch Time
+ Compact

+ Easy to do arithmetic actions without any libraries, i.e. var tomorrow=now()+60*60*24

- Not human-readable

- Cannot represent dates before 1 January 1970

- Cannot represent dates after 19 January 2038 (if using Int32)

- Timezone and offset are "external" info, there is ambiguity if the value is UTC or any other offset.

- Officially the spec supports only seconds.

- When someone changes the value to milliseconds for better resolution, there is an ambiguity if the value is seconds or milliseconds.

- Older than ISO 8601 format

- Represents seconds since 1970 (as opposed to instant in time)

- Precision of seconds

ISO 8601 Time
+ Human readable

+ Represents instant in time, as opposed to seconds since 1970

+ Newer then Unix time format

+ Specifies representation of date, time, date-time, duration and interval!

+ Supports an offset representation

+ Precision of nanoseconds

- Less compact

- For any arithmetic actions, reach library is required (like java.time.OffsetDatetime)


Both are unambiguous and easy to parse in programs. The benefit of epoch like you have mentioned is that it is smaller and will be faster to process in your program. The downside is it means nothing to humans.

iso8901 dates are easy to read on their own and don't require the user to translate a number in to a recognizable date. The size increase in iso8601 is unnoticeable when compared to much much larger things like images.

Personally I would pick ease of reading over speed for an API as it will cut down on debugging time while inspecting values sent and received. In another situation such as passing times around internally you may wish to choose the speed of an integer over text so it depends which you think will be more useful.

Tags:

Epoch

Iso8601