Diskussion:Unixzeit

message: Ich halte es mitlerweile für bedenklich, dass die Änderungen zu Schaltsekunden noch immer nicht aufgenommen wurden. Die jetzt noch veröffentlichten Erläuterungen sind schlicht falsch! Sie haben meiner Arbeitsgruppe im Vertrauen auf Wikipedia 14 Tage Arbeit gekostet. (nicht signierter Beitrag von 194.114.62.203 (Diskussion) 10:19, 12. Mai 2018 (CEST)
replies: text: Das liegt sicher unter anderem daran, dass du die Änderung nicht in der Zusammenfassungszeile begründet hast. Du machst es damit den Mitautoren nicht einfach, zu erkennen, ob deine Änderungen berechtigt sind oder nicht. Genauso solltest du auf der Diskussionsseite die Regelen beachten: Für ein neues Thema einen neuen Abschnitt beginnen (oben auf den Reiter "Abschnitt hinzufügen" klicken) und deinen Beitrag unterschreiben (mit dem Button über der Textbox bzw. mit --~~~~. Ich habe mal eine Zwischenüberschrift eingefügt. Du kannst sie gerne ändern. Viele Grüße, --Digamma (Diskussion) 10:46, 12. Mai 2018 (CEST)
thread_title:  Aktuelle Änderung 

message: Ich kapier nicht, was der Artikel mir sagen will. Unix-Zeit ist die Zeit in Sekunden seit Jahresbeginn 1970. Wer daraus ganz genaue Daten berechnen will, muß eine Liste mit den genauen Daten der seitdem eingefügten Schaltsekunden haben. Was gibt es da zu diskutieren oder unterschiedlich zu handhaben? --Maxus96 (Diskussion) 03:28, 15. Apr. 2019 (CEST)
replies: text: Oder ist es andersrum, und die Schaltsekunden werden, wie im Quellcodebeispiel, einfach komplett ignoriert und fehlen in der Unixzeit, nachdem die lokale Rechneruhr synchronisiert wurde? --Maxus96 (Diskussion) 03:47, 15. Apr. 2019 (CEST)
replies: text: Das zweite ist richtig. Unix-Zeit zählt die Schaltsekunden nicht mit. --Digamma (Diskussion) 19:03, 15. Apr. 2019 (CEST)
replies: text: Ok, danke. Ich hab das mal auf den Punkt gebracht. Das mit der unterschiedlichen Handhabung bezieht sich in der Quelle  auf Computer allgemein. Gruß,  --Maxus96 (Diskussion) 22:26, 15. Apr. 2019 (CEST)
thread_title:  Schaltsekunden 

message: Die Behauptung, 10.000 Jahre ließen sich mindestens sekundengenau mit einem Double darstellen, ist falsch. Korrekt sind ca. 2 Millionen Jahre. Nehmen wir einfach mal an, das Datum wird als Vorkomma- und die Zeit als Nachkommateil gespeichert, das findet sich in etlichen Implementierungen. Jetzt brauchen wir noch einen wortwörtlichen Tag 0. Microsoft Excel definiert den 0. Januar des Schaltjahres 1900 als Tag 0 (die Zeit davor wird nicht unterstützt). Gibt man in Excel die Zahl 0 ein und formatiert sie als Datum, erhält man Samstag den 0. Januar 1900, bei 60 Mittwoch den 29. Februar 1900. Das Jahr 1900 war jedoch kein Schaltjahr, sodass die Tage zwischen diesen beiden Datumspunkten den falschen Wochentag haben. (Microsoft: Days of the week before March 1, 1900 are incorrect in Excel, Memento des Internet Archive) Der Nachkommawert gibt an, welcher Anteil des Tages vergangen ist. ,75 ist somit 18 Uhr.  Vom 17. September 1989 bis zum 4. Juni 2079 (jeweils einschließlich) ist der Vorkommateil 16 Binärstellen lang, von denen durch Normalisierung nur 15 gespeichert werden müssen. Von den 52 Stellen der Mantisse eines Doubles bleiben also 37 für den Nachkommateil übrig. In den besagten 90 Jahren beträgt die speicherbare Genauigkeit somit 2-37 d ≈ 0,63 µs. Jetzt zur eigentlichen Frage: Um einen Tag in mindestens seine 86400 Sekunden unterteilen zu können, benötigt man \lceil \operatorname{lb} 86400 \rceil = 17 Nachkommastellen. Mit den verbliebenen 35 Bits plus dem impliziten Bit der Normalisierung ließen sich 236-1 d = 68719476735 d, also Kalenderdaten bis einschließlich 12. November 188149436 mit einer sekundengenauen Zeitangabe versehen, dies wird jedoch von der meisten Software aus anderen Gründen nicht unterstützt. Korrigiert mich, wenn ich mich verrechnet habe, sonst übernehme ich das irgendwann mal auf die Artikelseite. --Яedeemer 21:05, 24. Nov. 2019 (CET)
thread_title:  Genauigkeit von Double