Zeit ist ja nicht erst seit Einstein etwas sehr Relatives. Kurzfassung: Je schneller ich mich bewege, desto langsamer vergeht die Zeit, jedenfalls im Vergleich zu Zeitmess-System in unbewegtem Zustand...

Auch die Abbildung von Zeit auf digitaler Ebene hat ihre Tücken, zuletzt spuckte die Jahrtausendwende etlichen Admins in die Suppe.

Irgendwann gegen 2038 wird die Anzahl der seit dem 1. Januar 1970 vergangenen Sekunden so groß, dass sie auf 32-bittiger Software einen Fehler verursachen kann.

Die Unixzeit zählt die seit dem 1. Januar 1970 abgelaufene Zeit in Sekunden.[1] Am Dienstag, den 19. Januar 2038 um 03:14:08 Uhr UTC wird die Anzahl der vergangenen Sekunden die Kapazität einer vorzeichenbehafteten 32-Bit-Ganzzahl (maximal 2.147.483.647, 2³¹−1) überschreiten.[2] Das signifikanteste Bit (MSB) wird laut Konvention dazu verwendet, positive und negative Zahlen zu unterscheiden (Vorzeichen im Zweierkomplement), sodass die Zählung bei einer Überschreitung des Wertes 2.147.483.647 (binär 01111111111111111111111111111111) in den negativen Bereich springt (z. B. −2.147.483.648 binär 10000000000000000000000000000000). Das führt bei einer ungenügend implementierten Konvertierung von Unixtime zu Datum und Uhrzeit ungewollt zu einem Wert, der vor Beginn der POSIX-Epoche (1. Januar 1970) liegt.
(Quelle: Jahr- 2038-Problem bei Wikipedia)

Vergleichsweise harmlos dagegen sind die Folgen der Winter- und Sommerzeitumstellung. Die meisten Systeme können es automatisch. Die meisten Menschen bleiben einfach im Herbst eine Stunde länger im Bett und schlafen im Frühjahr dafür eine Stunde weniger. Manche jammern jetzt laut darüber - und die armen Kühe, deren biologische Uhr sich anscheinend nicht automatisch umstellt.

Merkwürdig allerdings, dass knapp 40 Jahre nach Einführung der Sommerzeit einer der führenden Softwarehersteller (SAP) immer noch ein Problem mit der Umstellung hat:

Like all the software that deal with local time will be confused when the computer clock traverses twice
through the same points in time, SAP system is no exception. With many delivered SAP systems, the "system time", that is, "wall clock time", accessible via SY-UZEIT, SY-DATUM, is used for control-relevant timestamps. With double hours this could lead to consistency problems. If, for example, timestamp1 is taken at point 2:30 summer time and timestamp2 is taken at point 2:15 winter time, the timestamp comparison timestamp1 > timestamp2
leads to an incorrect result. These inconsistent records are stored in the database, and cannot be solved by system reboot ...
(Quelle: Zhi Lue in SAP White Paper am 24.01.2012

Seine Empfehlungen:

There are three ways to deal with Daylight Saving Time:

A Two hour downtime method: Completely avoid running SAP system during this double hour.
B One hour downtime method: See Note 102088
C Zero downtime method: Use the default “stretched time”.
(Quelle: Zhi Lue in SAP White Paper am 24.01.2012)

"Streched time" bringt einen zur Ausgangsthese "Zeit ist relativ" zurück.

Die beiden anderen Empfehlungen "downtime" wirken im Jahr 2016 zumindest seltsam. Merkwürdig, dass es billiger ist, die SAP-Admins eine Nachtschicht machen zu lassen als da eine gescheite Zeitumstellungssoftware zu schreiben.