Przekazywanie czasu - ISO 8601 czy Epoch?

0

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-10T0839Z) 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-19T1657-08:00
1990-12-31T2360Z
1990-12-31T1560-08:00
1937-01-01T1227.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?

1

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

1

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).

1 użytkowników online, w tym zalogowanych: 0, gości: 1