Diskussion:Unixzeit/Archiv

message: Hallo,
die Verwendungsbeispiele vom date-Kommando oder gar die C-Implementierung von mktime ist ja ganz nett, aber vor allem letzteres ist absolut überflüssig, weil es in der libc schon implementiert ist. Da ich nicht einfach Texte weglöschen will -- was machen wir damit? --Benji 22:33, 28. Nov. 2009 (CET)
thread_title:  Unix-Kommandos und Beispielcode 

message: Die beiden letzten Einträge der Beispiel-Tabelle:
  2222222222  =  2. Juni 2040 02:57:02 
  4294967296  =  7. Februar 2106 05:28:16 
sind meines Erachtens falsch, denn die Unixzeit modula 86400 ergibt ja die Uhrzeit in Sekunden.
2222222222 mod 86400 ergibt aber 14222 Sekunden, also 03:57:02 und nicht 02:57:02.
Und bei 4294967296 müsste die Uhrzeit 06:28:16 sein (23296 Sekunden).
-- Jb 42 12:31, 17. Dez. 2009 (CET)
replies: text: Bitte, korrigier es :-) --Benji 21:36, 17. Dez. 2009 (CET)
thread_title:  Fehler in der Tabelle Besondere Werte 

message: Die 19. Zeile von int main() lautet:
: if( (j==2) && (j%4==0 && (j%100!=0 || j%400==0)) )
Dieser Ausdruck müsste meines Erachtens lauten:
: if( (j==2) && (jahr%4==0 && (jahr%100!=0 || jahr%400==0)) )
Leider weiß ich nicht, welche Programmiersprache das ist. Vermutlich C, und darin kenne ich mich nicht besonders gut aus, kann es also nicht überprüfen bzw. compilieren.
Insbesondere weiß ich nicht, ob (jahr%100!=0 || jahr%400==0) überhaupt zulässig ist. Ich würde vermuten, dass der Ausdruck unbedingt geklammert werden muss, also ((jahr%100!=0) || (jahr%400==0)), weil er sonst vom Compiler missverstanden wird.
Außerdem gibt es noch einige Kleinigkeiten, die ich für änderungswürdig halte:
Verwirrend ist, dass kurz vor Ende plötzlich eine Variable xxxx auftaucht.
Die anderen Eingangsgrößen (jahr, monat, tag, ...) werden doch auch am Anfang deklariert und definiert, warum nicht auch an dieser Stelle:
: int offset_cest=3600;   //Zeitzonendifferenz der deutschen Zeit zur UTC in Sekunden
Eigentlich würde ich die Zeitzonen-Umrechnung aber komplett aus der Formel herausnehmen, und stattdessen einfach dazuschreiben, dass die Eingangsgrößen sich als UTC verstehen. Es ist zwar edel, dem Leser auch gleich noch eine Zeitzonen-Umrechnung mitliefern zu wollen, aber in der vorliegenden Form nützt sie ihm wenig.
Warum wird für sekunde das Format long benutzt, für minute aber nur int? Ein Integer-Überlauf ist bei beiden Variablen gleichermaßen nicht zu erwarten, sondern nur bei der Variablen unix_sekunden.
Außerdem fällt auf, dass das Syntax-Highlighting von Wikipedia anscheinend nicht vollständig funktioniert, denn in Zeile 4 wird bei minute=30 die 30 blau geschrieben, bei stunde=20 hingegen die 20 schwarz.
Nach der Einleitung "Möchte man die Unixzeit zu einem bestimmten Zeitpunkt ... berechnen ..." erwartet man eine allgemeine Funktion, stattdessen wird nur der 26.11.2009 20:30:10 berechnet.
Hier würde ich entweder die Einleitung ergänzen: "... folgenden Rechenweg bewerkstelligen, der beispielsweise die Unixzeit für den 26.11.2009 20:30:10 MEZ berechnet".
Oder man ändert gleich die Funktion von
: int main()
nach
: long unixzeit(int jahr,monat,tag,stunde,minute,sekunde)
--Jb 42 19:47, 6. Jan. 2010 (CET)
replies: text: Ja, der Code ist nicht richtig. Aber meiner Meinung nach ist der Code hier absolut nicht notwendig und sollte entfernt werden nach WP:TF und WP:WWNI. --Fomafix 10:59, 11. Jan. 2010 (CET)
thread_title:  Fehler im Rechenweg-Code-Beispiel 

message: Fehlt nicht die time_t party zu 1415926535 ??? letz PI...
gruss,
david (nicht signierter Beitrag von 85.126.245.111 (Diskussion | Beiträge) 13:08, 19. Feb. 2009 (CET)
thread_title:  PI-Party 

message: Weiß hier jemand, warum Googles Datenbanken nicht mit dem Datum 31.12.1969 umgehen können? Es werden anscheinend Seiten aus den Indizes von Google gelöscht, die den Zeitstempel enthalten. -- Linksunten 14:55, 22. Mär. 2011 (CET)
replies: text: Das hat nichts mit UNIX zu tun, vielleicht aber mit der Google Implementierung. Selbst der 1.1.1970 liefert bei Google in Kalifornien in den ersten 8 Stunden einen negativen Zeitstempel. Wer weis wie die Google Datenbankanfragen mit soetwas umgehen. 
 adb
 0x80000000=Y
                1901 Dec 13 22:45:52
zeigt, daß UNIX mit negativen Werten keine Probleme hat. --Schily 12:19, 8. Apr. 2011 (CEST)
thread_title:  "31.12.1969"-Bug 

message: Unter angegebenem Link http://www.google.de/logos/logos09-1.html#logo-unix1234567890 ist das Doodle nicht mehr zu finden.
Unter http://www.google.com/doodles/finder/2009/All%20doodles sollten eigentlich alle Doodles aus 2009 angezeigt werden, aber auch da fehlt das zur Unixzeit. Ich habe den alten Link jetzt erst einmal entfernt. --Eddie 12:32, 2. Jan. 2012 (CET)
replies: text: Unter http://www.googlewatchblog.de/2009/02/google-doodle-unix-time-1234567890/ wird das Google Doodle aufgeführt. --Fomafix 12:55, 2. Jan. 2012 (CET)

text: Danke. Ich habe den Link ergänzt. --Eddie 14:24, 7. Jan. 2012 (CET)
thread_title:  Doodle zur Unixzeit 1234567890 

message: "Gibt es eine Quelle für das Speichern eines Zeitstempels in einer Gleitkommazahl? Welche Systeme machen den sowas wirklich?", mit diesem hilfreichen Kommentar wurde der entspr. Nonsens entfernt - denn es gibt keine Quelle, und es wäre auch sehr wenig sinnvoll. Natürlich könnte man einen Digitalcomputer mit Pressluft betreiben und ein Auto mit siebzehneckigen Rädern, es wäre aber doch relativ subsubsuboptimal. Um den Hoax mit der floating-point-Arithmetik zu erkennen, braucht man nicht einmal Informatik-Erstsemester-Studienabbrecher zu sein...da wollte wohl jemand testen, über wie lange Zeit barer Unsinn in der Wikipedia erhalten bleibt. Danke für  die Aufmerksamkeit, lieber anonymer 88.78.111.102. --BGVA3 (Diskussion) 18:58, 12. Dez. 2012 (CET)
thread_title:  Zeitstempel in einer Gleitkommazahl - so ein Unsinn 

message: Der Wert -11644473600 für den 1. Januar 1901 00:00:00 ist doch sicher falsch, oder unterliege ich einem Denkfehler? (nicht signierter Beitrag von 188.192.157.174 (Diskussion) 16:21, 13. Feb. 2013 (CET)
replies: text: Sehe ich auch so. Wie der Artikel schon sagt: "Unixzeiten vor dem 13. Dezember 1901 20:45:52 UTC sind mit einer vorzeichenbehafteten 32-Bit-Zahl auch nicht darstellbar, da die Zeitstempel kleiner als −2.147.483.648 wären." Noch mal ungefähr elf Monate zurück, gibt - auch wenn man mehr als 32 Bit benutzt - sicherlich nichts in der Größenordnung von -11.644.473.600 --Carl B aus W (Diskussion) 18:53, 16. Feb. 2013 (CET)
thread_title:  Falscher Wert in Tabelle? 

message: Was ist genau an der 1 333 333 337 interessant ist damit ein lang gezogenes 1337(leet) gemeint oder hat es mit 4F 79 0D 59 wtwas auf sich was sich ja, wieder in Hexspeak zu AFTGODSG.
Danke --87.162.239.207 16:42, 5. Mär. 2012 (CET)
replies: text: Moin, dem Bearbeitungskommentar nach wohl ersteres – ist das ein sinnvoller Eintrag? --El Grafo (COM) 18:18, 5. Mär. 2012 (CET)

text: ich verstehe das mit der 1333333337 nicht. Könnte das ein Indiz dafür sein, dass es nicht sinnvoll ist? --Carl B aus W (Diskussion) 00:12, 18. Dez. 2012 (CET)
replies: text:  habe es gelöscht --Carl B aus W (Diskussion) 17:10, 17. Feb. 2013 (CET)
thread_title:  1333333337 Erklärung 

message: Hallo,
die Aussage, die Unixzeit würde zu irgendeinem Zeitpunkt nicht sekundengenau sein, ist nicht richtig. Ich würde den ersten Absatz des Kapitels so abändern:
:Schaltsekunden werden nicht mitgezählt, sondern die Unixzeit wird mit der UTC-Zeit synchronisiert. Genauer: während der Schaltsekunde läuft die Unixzeit weiter, und wenn die UTC-Zeit von 23:59:60 auf 00:00:00 springt (nach Ablauf der Schaltsekunde), dann wird von der Unixzeit eins subtrahiert. Ab diesem Zeitpunkt durchläuft sie also nochmals den gleichen Wertebereich wie in der Sekunde zuvor. Die Unixzeit-Angaben während der Sekunde, die der Schaltsekunde folgt, sind somit mehrdeutig: sie entsprechen jeweils zwei Zeitpunkten der UTC-Zeit (Atomzeit), die sich um eine Sekunde unterscheiden.
:Durch das doppelte Durchlaufen einer Sekunde wird erreicht, das sowohl die aktuelle Unixzeit sekundengenau läuft, als auch, das alte Unixzeit-Angaben sekundengenau bleiben. Das kann man leicht testen, die Unixzeit 0 (Null) muss genau Do 1. Jan 00:00:00 UTC 1970 ergeben (Auf der Unix/Linux-Shell: date -u -d @0).
 
Der zweite und dritte Absatz erübrigen sich damit auch. Bei der POSIX-Diskussion geht es IMHO nicht um die Schaltsekunde, sondern um die Genauigkeit der Unixzeit, eine Sekunde ist zu wenig für Vergleiche der Änderungszeit von Dateien. Das ist soweit richtig erklärt, es gehört nur nicht hierher.
Die Erwähnung der Schaltsekunde in der Einleitung würde ich auch rausnehmen.
mfg --McTheSpoon ✉ 10:54, 5. Feb. 2014 (CET)
replies: text: Ich habe mal den ersten Absatz im Wesentlichen durch deine Formulierung ersetzt. Deinen zweiten Absatz habe ich nicht genommen, ich verstehe ihn nicht. --Digamma (Diskussion) 10:51, 9. Sep. 2014 (CEST)
thread_title:  Schaltsekunde 

message: Hallo,
ich fände es schön, wenn man aufnehmen könnte, warum der der 1.1.1970 gewählt wurde. Ich bin deshalb auf diese Seite gekommen, nicht fündig geworden, und denke, vielen geht es ähnlich. 
Gibt es Informationen über Gründe? Falls nicht, könnte man vielleicht in den Artikel aufnehmen, dass die Gründe nicht bekannt sind?
mfg, --13:11, 7. Jan. 2017 (CET)
thread_title:  Wahl des Datums 

message: was keine nennenswerte Beschränkung des Wertebereichs bewirkt.
doppelt negativ: keine Beschränkung
kann missverstanden werden in folgender Richtung:
Der Zeitbereich von 1970 +/-68 Jahren wird dadurch unwesentlich (= zusätzlich um ein geringes Maß) eingeschränkt
Daher meine Vorschläg für eine positive Formulierun:
... erweitert die darstellbaren Werte auf einen Zeitbereich von mehreren Billionen Jahren vor und nach 1970.
... erweitert die darstellbaren Zeiten auf einen Bereich von mehreren Billionen Jahren vor und nach 1970.
--Helium4 (Diskussion) 08:27, 27. Mär. 2018 (CEST)
thread_title:  Zählung via 64-Bit-Zahl