Az alapelv szerintem az, hogy ahol idővel számolunk, és nem csak egy indikátort mutatunk a DBA-nak vagy logba írunk, ott epoch time / time() / gettimeofday() / monotonic clock kell, nem string time.
Egy szerver default localtime-ja nem kellene, hogy bármit számítson egy production alkalmazásnál.

Különböző rendszerek között stringként utaztatni az időt általában csak hibák forrása. Lehet bármilyen modern ISO szabvány string, előbb-utóbb lesz olyan komponens, ami rosszul parseolja, timezone-t rosszul kezeli, DST-t elrontja stb. Timestampot kell küldeni, stringet csak a UI-nak.

Különösen akkor lesz ebből nagy probléma, amikor bekerül egy 3rd party vagy legacy rendszer a láncba, amire nincs ráhatásunk, és utólag kell workaroundokkal és hackekkel kezelni a különböző time formatokat és timezone hibákat.

!Nyilván ez nem vonatkozik olyan adatokra, mint születési dátum, történelmi események stb., mert azok nem egy konkrét timestampet jelentenek, hanem naptári dátumot. A probléma ott kezdődik, amikor valaki timestamp jellegű adatokat string formátumban kezd rendszerek között küldözgetni és azokkal számolni.!<

!Ráadásul az sem igaz, hogy integer timestamp mellett minden probléma meg van oldva. A DST eltűnik, de attól még a rendszerórák el tudnak csúszni, NTP korrigálhat, VM pause lehet, stb., és wall clock időből számolva simán kijöhet negatív vagy nulla időtartam. Nagyon érzékeny időtartamot helyileg monotonic clockkal kell mérni, nem epoch különbséggel. Elosztott rendszerek esetén meg logical clock, transaction id, lamport clock, stb.!<