Gibt es Bestrebungen, die Unixzeit neu zu definieren bzw. zu ersetzen?

[Binaermensch]

Hallo!

Gibt es Bestrebungen die Unixzeit durch einen neuen Standard zu ersetzen, welcher nicht solche Stolperfallen bietet / Mankos hat wie die Unixzeit?

Die Mankos die ich meine sind im Artikel Unix_time (http://en.wikipedia.org/wiki/Unix_time) der englischsprachigen Wikipedia zu finden.


Zusammengefasst:
Durch die (m.M.n. saublöde) Definition der Unixzeit kann es muss es bei strikter Einhaltung des Standards zu Ungleichmäßigkeiten im Zeitverlauf kommen.


Bestimmte Uhrzeiten können nicht eindeutig in der Unixzeit abgebildet werden
umkehrt kann es vorkommen, dass es für bestimmte Unix-Uhrzeiten garkeine Entsprechung in der Realität geben kann.


Hintergrund:
Unixzeit verwendet UTC. Laut Unixzeit muss ein Tag exakt 86'400s lang sein. UTC sieht jedoch auch Tage mit 86'399s bzw. 86'401s Länge vor. (Schaltsekunden.)

Um die Definition der Unixzeit nicht zu verletzen, müssen also bestimmten Unixzeitpunkten gleich zwei Zeitpunkte in der Realzeit zugeordnet werden.

Beispiel:
Sowohl 1998-12-31T23:59:60 UTC als auch 1999-01-01T00:00:00 UTC entsprechen der Unixzeit 915148800


Danke! :)
Binärmensch

[ESAD]

da ein "lineares" fortlaufen der zeit gegeben ist ist die umrechnung realzeit unixzeit bei einem großteil der anwendungen nicht so wichtig siehe z.B. Lamport Algorithmus

[Lokadamus]

da ein "lineares" fortlaufen der zeitmmm...

Nein, ist alles kaputt :usad: http://en.wikipedia.org/wiki/Leap_second

Wenn wir dann noch die TAI- Zeit betrachten, dann stimmt die ganze Zeitrechnung eh nicht mehr, schliesslich geht die schon ganze 32 Sekunden falsch :eek:. Die Unixtime/ Atomuhr ist damit nur noch als Schrott zu betrachten :|.

[ESAD]

bei der unix zeit ist trotzdem ein lienares fortlaufen gegeben ... ergo ists egal der admin kriegt vl. probleme die logs richtig zu lesen aber auch hier ist das lineare fortlaufen der zeit wichtiger als die richtigkeit

und es gibt auf der welt 4 verschiedene zeitrechnungsarten von denen ich weiß und jede ist wissenschaftlich korrekt und jede anders who cares (die die im laufe der zeit durch "richtigere" ersetzt worden sind mal außen vor genommen)

[Binaermensch]

bei der unix zeit ist trotzdem ein lienares fortlaufen gegeben ...Falsch.

Auszug aus Wikipedia, weil ich es selbst nicht besser ausdrücken könnte:

When a leap second occurs, so that the UTC day is not exactly 86 400 s long, a discontinuity occurs in the Unix time number. The Unix time number increases by exactly 86 400 each day, regardless of how long the day is. When a leap second is deleted (which has never occurred as of 2008), the Unix time number jumps up by 1 at the instant where the leap second was deleted from, which is the end of the day. When a leap second is inserted (which has occurred on average once every year and a half), the Unix time number increases continuously during the leap second, during which time it is more than 86 400 s since the start of the current day, and then jumps down by 1 at the end of the leap second, which is the start of the next day. For example, this is what happened on strictly conforming POSIX.1 systems at the end of 1998:

[...]

[Lokadamus]

Falsch.

Auszug aus Wikipedia, weil ich es selbst nicht besser ausdrücken könnte:mmm...

Mal gaanz doof gefragt: Wo ist Problem?

Wir haben gelernt, dass die Atomuhr falsch läuft und sonst ist nichts besonderes passiert.
Aufgrund der genauen Angaben von der Unixtime und der Angabe, wann immer eine Sekunde hinzu oder abgezogen wird, kann jeder auf die Unixtime aufsetzen und es so erweitern, dass jede Anwendung die "richtige" Zeit erhält.

Im Alltag ist es aber wie schon gesagt wurde, palle, weil die Atomuhrzeit in den meisten Fällen als Grundlage für NTP (Network Time Protokoll) genutzt wird.

[puntarenas]

Ich stelle mir das als Laie so vor, dass man in der Praxis halt den aktuellen Wert erstmal speichert und dann später die Differenz errechnet und so die Laufzeit bekommt. Dabei wären die angesprochenen Probleme ja irrelevant. Unixtime scheint halt zur Eindeutigen Benennung eines exakten Zeitpunkts ungeeignet.

Gleich noch eine DAU-Frage hinterher, für sowas bringen die Standardlibs der Programmiersprachen sicher eigene Funktionen mit. Wenn ich also Beispielsweise in Java die Datumsfunktion benutze, würde diese sich unter einem Unix-System dann der Unix Time bedienen und die angesprochenen Probleme erben?

[Gast]

Ist nicht nötig, da der Timestamp bei 64Bit Systemen lang genug ist...Und bis 2020 oder wann das ist wird wohl jeder 64Bit haben!!

[rotalever]

Ist nicht nötig, da der Timestamp bei 64Bit Systemen lang genug ist...Und bis 2020 oder wann das ist wird wohl jeder 64Bit haben!!
Und was ist mit Embedded Systems? Den ganzen Geräten auf Linux basis?
Ein user hat berichtet, dass er die Zeit auf 2038 gestellt hat, sein Linux hat 5 Minuten zum Booten gebraucht und ist dann abgestürtzt..

[Lokadamus]

Ich stelle mir das als Laie so vor, dass man in der Praxis halt den aktuellen Wert erstmal speichert und dann später die Differenz errechnet und so die Laufzeit bekommt. Dabei wären die angesprochenen Probleme ja irrelevant. Unixtime scheint halt zur Eindeutigen Benennung eines exakten Zeitpunkts ungeeignet.

Gleich noch eine DAU-Frage hinterher, für sowas bringen die Standardlibs der Programmiersprachen sicher eigene Funktionen mit. Wenn ich also Beispielsweise in Java die Datumsfunktion benutze, würde diese sich unter einem Unix-System dann der Unix Time bedienen und die angesprochenen Probleme erben?mmm...

Für Logfiles und ähnliches ist die Zeitbestimmung genau genug.
Wie gesagt, das Netzwerk sollte sich per NTP abgleichen, wodurch alle PCs die selbe Uhrzeit bis auf die Sekunde (aber nicht Hundertstel) genau haben.
Die Elektronik selber hat also keine Probleme damit.

Spontan würde ich bezüglich der Libs auf Nein tippen. Entweder wurde die Atomuhr korrigiert oder es ticken eh alle PCs falsch ;).Ist nicht nötig, da der Timestamp bei 64Bit Systemen lang genug ist...Und bis 2020 oder wann das ist wird wohl jeder 64Bit haben!!Hat jede aktuelle Distri schon lange.Und was ist mit Embedded Systems? Den ganzen Geräten auf Linux basis?
Ein user hat berichtet, dass er die Zeit auf 2038 gestellt hat, sein Linux hat 5 Minuten zum Booten gebraucht und ist dann abgestürtzt..Dann soll er hoffen, dass das Gerät noch 30 Jahre hält ;).

[HellHorse]

Ist nicht nötig, da der Timestamp bei 64Bit Systemen lang genug ist...Und bis 2020 oder wann das ist wird wohl jeder 64Bit haben!!
Hat nichts mit dem Thema zu tun.

[HellHorse]

Wenn ich also Beispielsweise in Java die Datumsfunktion benutze,
1. Fehler

würde diese sich unter einem Unix-System dann der Unix Time bedienen
Kannst den Konjunktiv weglassen.

und die angesprochenen Probleme erben?

import static junit.framework.Assert.assertFalse;
import org.junit.Test;

import java.util.Calendar;
import static java.util.Calendar.*;
import java.util.GregorianCalendar;
import java.util.TimeZone;

public class FuckedUnixTime {

@Test
public void fuckedEquals() {
TimeZone utc = TimeZone.getTimeZone("UTC");

Calendar nineteenNinetyEight = new GregorianCalendar(utc);

nineteenNinetyEight.set(YEAR, 1998);
nineteenNinetyEight.set(MONTH, DECEMBER);
nineteenNinetyEight.set(DAY_OF_MONTH, 31);
nineteenNinetyEight.set(HOUR_OF_DAY, 23);
nineteenNinetyEight.set(MINUTE, 59);
nineteenNinetyEight.set(SECOND, 60);
nineteenNinetyEight.set(MILLISECOND, 0);

Calendar nineteenNinetyNine = new GregorianCalendar(utc);

nineteenNinetyNine.set(YEAR, 1999);
nineteenNinetyNine.set(MONTH, JANUARY);
nineteenNinetyNine.set(DAY_OF_MONTH, 1);
nineteenNinetyNine.set(HOUR_OF_DAY, 0);
nineteenNinetyNine.set(MINUTE, 0);
nineteenNinetyNine.set(SECOND, 0);
nineteenNinetyNine.set(MILLISECOND, 0);

assertFalse(nineteenNinetyEight.equals(nineteenNinetyNine));
}

}

Jetzt rate mal, was da raus kommt.

[Binaermensch]

Mal gaanz doof gefragt: Wo ist Problem?

Wir haben gelernt, dass die Atomuhr falsch läuft und sonst ist nichts besonderes passiert.Damit bringst du mich jetzt aus dem Konzept.

Warum läuft die Atomuhr falsch? :|

Aufgrund der genauen Angaben von der Unixtime und der Angabe, wann immer eine Sekunde hinzu oder abgezogen wird, kann jeder auf die Unixtime aufsetzen und es so erweitern, dass jede Anwendung die "richtige" Zeit erhält.Genaugenommen nicht.

Wenn du nurmehr den Timestamp 915148800 hast, kannst du im nachhinein nicht mehr mit bestimmtheit sagen ob der 31. Dez. 1998 23:59:60 UTC oder der 1. Jan. 1999 00:00:00 UTC gemeint war.

Ich stelle mir das als Laie so vor, dass man in der Praxis halt den aktuellen Wert erstmal speichert und dann später die Differenz errechnet und so die Laufzeit bekommt. Dabei wären die angesprochenen Probleme ja irrelevant. Unixtime scheint halt zur Eindeutigen Benennung eines exakten Zeitpunkts ungeeignet.Auf den hervorgehobenen Text bezogen:

Dein Gedankengang ist logisch, genau so sollte man annehmen können das es ist.
Leider ist es jedoch nicht so. Wenn du eine derartige Laufzeitmessung am 1970-01-01 gestartet hättest, würdest du heute auf einem POSIX-konformen System ein um 32s falsches Ergebnis erhalten.
Warum? Weil Sekunden doppelt gezählt wurden.

(Das war jedoch noch nicht der Worst-Case. Im schlechtesten Fall könntest du sogar eine negative Laufzeit erhalten.)

Mich stören nicht so sehr die Konsequenzen die das hat (die 32s kann man verschmerzen), mich stört viel eher dass derartige Ungereimtheiten aktueller POSIX-Standard sind.

[Lokadamus]

Damit bringst du mich jetzt aus dem Konzept.
Warum läuft die Atomuhr falsch? :|
Genaugenommen nicht.mmm...

Vielleicht hab ich das falsch verstanden, aber
http://en.wikipedia.org/wiki/Leap_second
UTC is counted by atomic clocks, but is kept approximately in sync with UT1 (mean solar time) by introducing a leap second when necessary.

Wenn ich es richtig versteh, bedeutet es, dass die Atomuhrzeit eigentlich falsch läuft und immer wieder angepasst wird.Wenn du nurmehr den Timestamp 915148800 hast, kannst du im nachhinein nicht mehr mit bestimmtheit sagen ob der 31. Dez. 1998 23:59:60 UTC oder der 1. Jan. 1999 00:00:00 UTC gemeint war.Ich würde immernoch sagen, dass du eine eigene Anwendung schreiben kannst, die dir beide Zeiten anzeigt. Welche du davon gebrauchen kannst, must du selber wissen.Mich stören nicht so sehr die Konsequenzen die das hat (die 32s kann man verschmerzen), mich stört viel eher dass derartige Ungereimtheiten aktueller POSIX-Standard sind.Vielleicht liegt es daran, dass man keine ordentliche Formel erstellen kann, wann eine Leap Second auftritt und wann nicht bzw. es ziemlich umständlich ist anstatt einfach die Sekunden zu zählen.