Przekazywanie czasu - ISO 8601 czy Epoch?

Cześć,
Jak w swoich projektach przesyłacie informacje o czasie, na przykład w JSONie. I dlaczego akurat w taki sposób. Konkretnie, jakie wady i zalety, ma ISO 8601 (na przykład 2020-03-10T08:44:39Z) a jakie epoch (na przyklad 1583749154495).

Potencjalne zalety używania epoch time:

• Timezone-less. W aplikacjach webowych możemy zwracać typ number na front, a już przeglądarka dopasuje strefę czasową dla użytkownika
• Nie ma problemu parsowania
• Zajmuje mniej miejsca (w 99% przypadków raczej nieistotne)

Zalety daty jako stringa:

• Human readable format (chociażby w logach)
• Obowiązuje jako obecny standard
• Nie jest podatny na błędy w obsłudze epoch time (w teorii epoch to czas od 01.01.1970, ale nie w każdym języku: (https://en.wikipedia.org/wiki/System_time)

Problem z ISO 8601 może być też potencjalnie taki, że nawet w jednym standardzie formaty różnią się między sobą:
1996-12-19T16:39:57-08:00
1990-12-31T23:59:60Z
1990-12-31T15:59:60-08:00
1937-01-01T12:00:27.87+00:20
Według oficjalnej dokumentacji RFC 3339 (https://tools.ietf.org/html/rfc3339#section-5.8) , wszystkie powyższe formaty są akceptowalne.
Czego Wy używacie, i dlaczego?

Preferuję ISO, bo interpretacja jest jednoznaczna dla komputera i łatwa dla człowieka.

Ok, ale co jest trudnego w sparsowaniu ww. formatów? Zwłaszcza czym różni się 1 i 3 przykład? Bo dla mnie to całkiem łatwe:

\d{4,}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[+-]\d{2}:\d{2})

Do tego tylko wymagania co do samych wartości, ale sam format jest bardzo prosty. Dodatkowo nie masz problemu z leap seconds (bo np. Google używa smearing). A jak chcesz mieć strefę czasową to i tak musisz podać, bo (Z|[+-]\d{2}:\d{2}) nie definiuje strefy czasowej, a tylko różnicę względem UTC (a to olbrzymia różnica).