Diskussion:Unixzeit/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Unixzeit/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Unixzeit/Archiv#Thema_1

Leap Seconds

Und was ist mit den sogenannten Leap Seconds? Das sind die Sekunden, die eingefügt werden, wenn man die Erdrotation wieder ein wenig an die Uhrzeit synchronisieren möchte ... da müsste doch unixzeit langsam auseinanderlaufen. danke, --Abdull 11:47, 2. Mär 2005 (CET)

Der POSIX Standard sagt im Kapitel Seconds Since the Epoch dazu: "A value that approximates the number of seconds that have elapsed since the Epoch." und "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." und: "As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds." --SET 00:38, 18. Mär 2005 (CET)

Also ich würde sagen, der Artikel ist so nicht 100% richtig mit der Behauptung:

Die Unixzeit zählt die vergangenen Sekunden seit dem 1. Januar 1970 00:00 h UTC.

Durch Schaltsekunden wird die Zeit immer künstlich zurückgedreht. Wenn man so möchte, stellt der Unix-Timestamp, so sicher bin ich mir mitterweile zumindest, die Anzahl der Sekunden seit 1.1.1970 00:00 UTC dar, falls KEINE Schaltsekunden eingefügt worden wären.

Wäre der Unix-Zeitstempel wirklich nach den mittlerweile verstrichenen Sekunden defniert, würde er mittlerweile 22 Sekundenim vergleich zur korrigierten UTC voreilen (es gab bereits 22 Schaltsekunden seit 1970).

Es wäre schön, wenn ein paar Geeks ihre Meinung dazu geben könnten.

Danke, --Abdull 14:34, 7. Apr 2005 (CEST)

Soweit ich weiss bezieht sich die Unixzeit (laut POSIX-Standard) auf GMT, nicht UTC (letzteres gab es damals noch nicht). GMT kennt keine Schaltsekunden. Auch ist es ja so, dass hier Sekunden gezählt werden, während GMT und UTC Datumsstandards sind - da GMT und UTC zum 1.1. 1970 noch synchron waren, macht es also keinen Unterschied. Ein Problem ergibt sich erst bei der Umrechnung von Unixzeit in ein menschenlesbares Format - dabei müssten eigentlich die Schaltsekunden berücksichtigt werden, POSIX sieht das aber nicht vor. Ob die Schaltsekunden berücksichtig werden, ob das Ergebnis also in der tat UTC ist oder GMT, kommt auf die implementation an. Da herrscht leider uneinigkeit... um das zitat von oben aus dem POSIX-Standard noch mal zu wiederholen: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." Nicht gut. Aber so isses eben. -- D. Dÿsentrieb ⇌ 18:15, 7. Apr 2005 (CEST)

Die Unixzeit zählt die Sekunden inkl. Schaltsekunden, bzw. es kennt gar keine Schaltsekunden, denn es kennt ja auch keine Jahre oder Tage, ist ja nur ein Integer, wie will man da was "einschalten?". Ob die UTC-Schaltsekunden berücksichtigt werden oder nicht spielt also nur bei der Umrechnung des Integers in ein "astronomisches" Datums/Zeitformat eine Rolle, wie eben UTC. Auf Unix-Systemen wird dieses mit Hilfe der zoneinfo Files gemacht. Und die können Schaltsekunden enthalten (dann müssen die auch regelmässig geupdatet werden, wenn man es ganz genau nimmt), siehe auch ctime(3) manpage.

Leider werden solche zoneinfo Files meistens nicht verwendet, eben weil sie wie oben von SET aufgeführt mit dem POSIX Standard kollidiert (86400 Sekunden pro Tag). Auf solchen Systemen muss der Benutzer, selbst hätte er eine exakte Systemuhr, die Zeit manuell nachstellen will er synchron mit der Welt bleiben und darum stimmt das mit den Sekunden seit 1.1.70 dort auch nicht. Aber das liegt nicht an der Unixzeit, sondern am blöden POSIX Standard bzw. den POSIX-Zoneinfofiles. Siehe auch /usr/src/share/zoneinfo/Makefile auf BSD-systemen. -- 195.49.2.166 14:56, 4. Aug 2006 (CEST)

"die Hälfte der Zeit bis zum 31-Bit-Überlauf"

"Ein besonderes Ereignis fand am 18. März 2005 statt, als um 01:58:31 UTC der Timestamp den binären Wert 1111111111 annahm. Zu diesem Zeitpunkt war die Hälfte der Zeit bis zum 31-Bit-Überlauf verstrichen."

Handelt es sich hier nicht vielmehr um den dezimalen (und nicht binären) Wert 1111111111? (Und müsste der binäre Wert nicht deutlich mehr Stellen haben?) Zudem liegt nicht das Jahr 2005, sondern 2004 in der "Mitte" zwischen 1970 und 2038, so dass auch dieser Teil mit der "Hälfte der Zeit" nicht ganz stimmen kann... --ingh � 14:56, 4. Okt 2005 (CEST)

ist mir auch sofort aufgestossen. ist imo blödsinn, so wie es da steht...

bezieht sich wahrscheinlich auf: http://www.heise.de/newsticker/meldung/57664 - die angabe ist natürlich dezimal!

Startzeit

Im Artikel wird die Startzeit 1.1.1970 00:00 Uhr angegeben. Die angegebenen Links am Ende verweisen auf zunächst hilfreich erscheinende Umrechnungstools. Die meisten dieser Tools ermitteln bei Eingabe der UNIX-Zeit 0s jedoch den 01.01.1970 um 01:00 Uhr! Da ich derzeit keinen Zugriff auf die Definitionen in den Standards habe, würde mich zunächst interessieeren, welches die definierte Startzeit am 01.01.1970 ist. Ich würde mich nicht wundern, wenn es eine ganz andere -- wie z.B. 12:00 Uhr -- wäre. Im zweiten Schritt sollte man wohl die Autoren der Umrechnungstools kontaktieren, und im dritten Schritt dann korrekt funktionierende Tools im Wikipedia-Artikel verlinken.

Es wäre schön, wenn jemand hierzu etwas weiß.

Wissen tu ich nix, aber ich glaube, es so verstanden zu haben:

Die Umrechnungstools, auf die Du hier verweist, rechnen in Ortszeit (UTC + 1 Stunde) um. Als es am 01.01.1970 nach UTC 00:00 Uhr war, war es hier 01:00 Uhr. Wenn man den Link 'Unix Timestamp Converter (beliebige Zeitzone einstellbar)' verwendet und als Zeitzone GMT einstellt kommt für die UNIX-Zeit 0s auch das die korrekte Uhrzeit 0:00 GMT herraus. Insoweit scheint mir das alles in sich schlüssig. (nicht signierter Beitrag von 195.49.2.166 (Diskussion) )

Also mich wundert ja, dass beim letzten Kommentar nicht ein paar Leute verwirrt waren und sofort dazu Stellung nahmen. Ich muss nämlich sagen, lieber Vorredner, dass du mehr durcheinander bringst als hilfst. GMT und UTC sind das Selbe; lediglich der Name wurde von GMT zu UTC geändert, soweit ich weiss. Und daher spreche ich nachstehend auch nur noch von der UTC-Zeit. Solltest du auch machen! (Falls es jemanden an dieser Stelle interessiert: UTC vernachlässigt die Sommerzeit. Also beim Umrechnen nicht vergessen! Manche Tools, wie dieses hier, beziehen diesen Umstand mit ein.) Des Weiteren, lieber Vorredner, sprich bitte nicht von "hier war es so und so spät". Wir wissen nämlich nicht wo du zu diesem Zeitpunkt warst. Nur so als Tipp! ;-)

Ach und wenn wir schon dabei sind: Ich finde es eigentlich nicht sehr sinnvoll, wenn hier von "schlüssig" gesprochen wird, denn das Thema "Zeitrechnung" ist sicherlich kein Leichtes (seit Jahrtausenden zerbrechen sich Menschen den Kopf darüber) und das Online-Werkzeug, auf das hier verwiesen wird, existiert auch nicht mehr in der Form wie es anscheinend einmal war. Ich habe nämlich nirgendwo eine Möglichkeit für das Einstellen einer Zeitzone entdeckt. Aber positiv finde ich daran, dass es nun auch auf die besagte Funktion verzichtet und dem Benutzer die Arbeit der Zeitzonenrechnung abnimmt. Es ermittelt automatisch den Standort des Benutzer-Computers und rechnet, abhängig davon, die Unix-timestamps richtig in Ortszeit zurück. Klasse Sache, finde ich! Ändert jedoch nichts daran, dass die Autoren der Tools dies zumindest kommentieren könnten, sodass man nicht konfus beim "Rückrechnen" dasteht.

Was ich am genannten Tool allerdings nicht verstehe ist, warum es nur Zeitangaben bis rückwärts maximal 1. Januar 1990 in Unix-timestamps verwandeln kann. Aber keine Kritik mehr am Autor, dessen Arbeit ja garnicht so schlecht ist.

Viel eher will ich kritisieren, wozu eigentlich ein Unix-timestamp eingeführt wurde? Das ist doch wohl der grösste Schwachsinn in der menschlichen Zeitrechnung gewesen. Und das alles nur, weil Bits'n'Bytes damals so kostbar und rar waren. Finde ich echt krass die Vorgehensweise der damaligen Techniker! --Asamaar 04:44, 24. Aug. 2008 (CEST)

Lieber Asamaar,

deine Diskussionsart ist aber auch nicht gerade allzufreundlich. Die Aussage der IP war ja letztlich nicht falsch, und was er mit der Floskel bei uns meinte, leuchet auch jedem ein.

Vielleicht solltest du versuchen, nicht ganz so überheblich daherzureden. Was soll denn diese völlig deplazierte und unqualifizierte Kritik an der Idee des Unix-Timestamps? Ohne dir jetzt zunahe treten zu wollen unterstelle ich dir, dass du den Sinn und Zweck dieses Timestamps nicht verstanden hast. Und wenn der Timestamp eines ist, dann garantiert nicht knauserig in Speicherplatz – 32 Bit für einen Zeitstempel zu verwenden, das waren 1970 *gigantische* Dimensionen, aber sie waren zukunftsweisend: Während wirklich knauserige Zeitstempelformate dem Jahr-2000-Problem unterliegen, ist der Unix-Timestamp noch über Jahre hinaus gültig. Abgesehen davon verwendet heute weltweit *jedes* ernstzunehmende Computersystem den Unix-Timestamp. Einfach deshalb, weil es sich um ein sehr einfaches, aber ebenso brilliantes Format handelt, mit dem Begriff Zeit umzugehen. Das sollte eigentlich auch Aussage des Artikels sein. Möglicherweise hat dieser in der Hinsicht noch Schwächen. --Benji 16:09, 24. Aug. 2008 (CEST)

Lieber Benji,

entschuldige wenn ich überheblich klinge, aber für mich (und die eigene Meinungen wird ja noch erlaubt sein) ist der UNIX-Timestamp ein schwachsinniges System. Dir ist nämlich sicher bekannt, dass es damit im Jahre 2038 aus und vorbei sein wird. Tja und nun frage ich dich ernsthaft: Was dann? Hast du schon 'ne Lösung? Soviel zur Qualifikation.

Des Weiteren bin ich keineswegs unfreundlich geworden, habe niemanden beleidigt, sondern lediglich sachlich kritisiert. Also warum legst du fest, ich sei "nicht gerade allzufreundlich"? Was bringt dich auf diese Meinung? Hast du nichts Besseres zu tun als hier Streit anzufangen? Sorry, dass ich das Thema "Zeit" sehr ernst nehme und mir auch sehr genaue Gedanken dazu mache, was du ja anscheinend nicht tust. --Asamaar 08:07, 25. Aug. 2008 (CEST)

Hallo Asamaar,

Ich habe keineswegs vor, Streit oder Unfrieden zu stiften. Mir kam ebendas nur bei deinem ersten Posting so vor. Tud mir leid, wenn ich damit daneben gelegen habe und du es nicht so gemeint hast.

Das Jahr-2038-Problem wird zu dem Zeitpunkt kaum mehr der Diskussion wert sein, denn, wie ja im gleichnamigen Artikel bereits steht, wird die Breite der Timestamp-Struktur dann einfach 64bit sein, die für alle Ewigkeiten reichen. Natürlich ist deine Meinung zugelassen und wird auch gerne angehört, aber ich hatte nun das Gefühl (und hab es auch jetzt noch), dass sie sehr einseitig ist. Was sagt den eine Aussage wie "der Unix-Timestamp ist ein schwachsinniges System" aus? Es fehlen Begründungen, warum du denn so denkst (und die, die du genannt hast, hab ich ja stets widerlegt) und vor allem, welches System du denn als besser empfindest (und warum es das nicht sein wird, hab ich ja auch schon versucht, darzulegen).

Der Punkt ist nämlich, dass eine gebrochene Zeitrechnung sowohl umständlich in der Handhabung ist, als sich auch als nicht zukunftssicher bzw. portabel herausgestellt hat (Jahr-2000-Problem). De facto ist Zeitrechnung mit dem Unix-Timestamp wesentlich perfomanter, weil man nur die für alle Computerrechenwerke sehr einfach durchzuführenden Grundrechenarten der Addition und Subtraktion benötigt. Hast du schon mal programmiert? Mit dem Unix-Timestamp geht es in allen Programmiersprachen und auf allen Plattformen in allen Betriebssystemen identisch. Es gibt kaum ein System, was genauso allgemeingültig in Computern verwendet werden kann. Und das hat seine Gründe.

Viele Grüße, --Benji 19:00, 25. Aug. 2008 (CEST)

Hallo Benji,

ich programmiere fast täglich und denke, in kommunikationstechnischer Hinsicht, über alles was du schilderst, Bescheid zu wissen. Univ. Dr. Prof. bin ich zwar keiner und kann dir daher auch kein "besseres" System, als die von dir erwähnte 64bit-Erweiterung, anbieten. Sollte mir mit meinem derzeitigen Wissensstand dennoch ein besseres einfallen, werde ich davon berichten. Aber bis dahin muss ich noch ein paar Bereiche der Mathematik durchackern.

Ich will jedoch auch anmerken, dass wir Menschen mit einer Datumsangabe wie z.B. 973937471 im täglichen Leben nichts anfangen. Der Rechner jedoch verarbeitet sie problemlos. Und jetzt kommt DIE Frage: Master oder Slave? Was willst sein, Benji? Ich bin nämlich der Meinung, Rechner sollten uns das Leben erleichtern und nicht erschweren. Wenn du also über meine letzte Frage hinausgekommen bist, will ich dir noch eine stellen: Lässt sich der, derzeit fast allerorts gültige, gregorianische Kalender einfach und ohne viel Aufwand in Unix-Zeitstempeln (und auch retour) rechnen? Und bitte glaube nun nicht, ich wäre aus Prinzip gegen alles und jenes. Im Gegenteil! Wir stehen auf der selben Seite, nur wünsche ich mir halt ein praktischeres System, DAS DEM MENSCHEN dient und nicht der Maschine. Die Maschine weiss z.B. nichts von Schaltsekunden, Erdrotation und Zeitabweichung. Sie weiss noch nicht einmal, dass sie auf unserem Planeten Arbeit für uns verrichtet. Ach und habe ich schon erwähnt, dass Maschinen auch nicht wissen wie lange eine Sekunde dauert? :-D

Ich wollte mit meinen posts einfach nur zum Nachdenken anregen. Vielleicht findet sich ja jemand der Spass daran hat, ein kongeniales System der Zeitrechnung zu entwickeln, welches Menschen und Maschinen in GLEICHER Weise dient. Zum Beispiel das der alten Maya muss ich mir selber noch sehr genau ansehen. Bin nämlich bereits im Ansatz davon fasziniert. Greetz! --Asamaar 02:33, 26. Aug. 2008 (CEST)

Nabend Asamaar,

dass der Unix-Timestamp ein rein computerorientiertes System ist, hab ich nie bezweifelt. Aber damit steht er in einer Reihe typischen Computersystemen aus den 70ern und 80ern – wie hierarchischen Dateisystemen (C:\WINNT\System32\Drivers\etc\hosts ist wie /usr/local/share/doc/binutils/README.gz nicht gerade sehr menschenfreundlich) oder Unix-Dateirechten (0774 – handlich, aber nicht einprägsam), um mal Beispiele aus der Unix-Welt zu nennen. Selbst (damalige) "Hochsprachen" wie Fortran oder die Programmiersprache C sind doch alles andere als für Menschen intiutiv brauchbar.

Mit der Zeit (zunehmender Popularität/Leistungsfähigkeit der Computer) haben sich immer (aus der Sicht des Computers) abstraktere bzw. (aus der Sicht von Menschen) intiutiver bedienbare Systeme/Programmiersprachen/Oberflächen gebildet. So wie die Desktopsuche heute die Unzulänglichkeiten der nicht mehr wegzudenkenden hierarchischen Dateisystemen kompensiert, tun Perl, Python oder Java ihr Übriges im Bereich der Programmiersprachen. GUIs wie das X Window System ersetzen kryptische Unix-Shells. Das geht doch alles in Richtung Maschine dient Mensch, nicht wahr? Letztlich muss heute kein Mensch einen Timestamp lesen können oder eingeben können, selbst als Programmierer braucht man das nicht mal mehr: Ein Timestamp wird halt durch ein High-Level-Objekt gekapselt, in Java heißt es z.B. einfach nur noch Date. Und wenn ich mir so die API-Dokumentation dazu anschaue, dann komme ich mir mit meiner time_t-Struktur in C doch wie aus dem letzten Jahrhundert vor. Was willst du mehr? Wozu ein komplett neues "Zeitsystem"? Korrekte Umrechnungen zwischen verschiedenen Kalendern und dem Unix-Timestamp sind sowieso unproblematisch, vgl. beispielsweise mktime für C oder eben Methoden für das Date und Calendar-Objekt in Java.

Mit Grüßen aus Kelkheim, --Benji 02:16, 28. Aug. 2008 (CEST)

Hallo Benji,

ich sag's mal ganz salopp: Du hast meinen letzten post nicht wirklich verstanden, Benji (Stichwort dazu findet sich in DEINEM letzten post: "mktime"). Ich versuche mir derzeit wirklich ernsthafte Gedanken zu einem neuen Zeitrechnungssystem zu machen und bin dabei auf gewisse, unvermeidliche Grenzen gestossen (eine von vielen ist z.B. "Startzeit", wie der Titel dieser Diskussion schon sagt). "Endzeit" und "Dauer" sind genauso Begriffe die mich bei meinen Denkanstrengungen innerlicht unzufrieden stimmen und mich noch mehr über der Materie brüten lassen.

Was ich aber definitiv weiss ist, dass ich jemandem zwar meine Ansichten klar machen kann, aber zum Querdenken zu bringen ist wohl doch eine Disziplin, in der ich eher ungeübt bin. Würde ich nämlich all das aufschreiben, was zu diesem Thema in meinem Kopf vorgeht, könnte ich wahrscheinlich Schränke voller Bücher damit füllen. Jedoch will ich mich abschliessend nicht polemisch geben und beschränke mich auf zwei Sätze: Benji, lies dir nochmal in Ruhe durch, was ich zuletzt geschrieben habe. Vielleicht verstehst du ja irgendwie doch noch, auf was ich anspiele."

Die Diskussion über den Begriff "Startzeit" ist für mich jedenfalls erledigt, da user "unsigned|195.49.2.166" alles Nötige (wenn auch etwas irritierend) erklärt hat und anscheinend auch niemand weiterer, ausser dir Benji, mitdiskutiert. Noch dazu weiss ich nicht, ob ich die nächsten Wochen Zeit zum posten finden werde und darum: Bis dann! (nicht signierter Beitrag von Asamaar (Diskussion | Beiträge) )

Moin Asamaar,

och, das ist aber eine unschöne Absage an unsere kleine Privatdiskussion, zudem sie doch gerade erst richtig in Fahrt kommt.

Ich habe dich (bis jetzt) zumindest so verstanden, dass du ein Zeitrechnungssystem für Computer suchst, welches die Schwächen des Unix-Timestamps nicht hat. Diese hast du konkretisiert, und ich hab dies "widerlegt", zusammenfassend:

Contra Timestamp	Lösung
Jahr-2038-Problem	64 bit-Timestamp
ist für Maschinen gemacht	Grund: Stammt aus Zeiten, wo Rechenleistung viel Geld wert war, und...
schlecht von Menschen benutzbar	...wird heutzutage durch Highlevel-Systeme abstrahiert
Benutzer ist Sklave der Maschine	nein, weil er mit dem Timestamp nie in Berührung kommt
Umrechung Gregorianischer Kalender ↔ time_t	Wie Timestamp sagt, sind Schaltsekunden problematisch, ansonsten liefern selbst libc-Funktionen gute Ergebnisse

In dem Punkt ist die Diskussion also zumindest zum Ende gekommen, da du keine neuen Argumente formuliert hast.

Gut, du möchtest ein ganz neues Zeitrechnungssystem erfinden. Um diesen Überlegungen nicht mit Totschlagargumenten wie Nicht das Rad neu erfinden oder UTC ist weltweiter Standard entgegenzutreten: Was genau stört dich an (z.B.) UTC? Letztlich können ja auch Maschinen gut damit umgehen, oder warum arbeitet z.B. die Wikipedia global mit der UTC?

Gegen Querdenken hab ich partout nichts, solange man sich verständlich ausdrückt. Zumindest sind wir über das Niveau der Timestamp ist Scheiße (Zitat von deinem ersten Post) hinaus.

Viele Grüße, --Benji 14:51, 1. Sep. 2008 (CEST)

Hi Benji, hab' derzeit äusserst wenig Zeit zur Verfügung, deswegen die Absage. Und darum mache ich's auch so kurz wie möglich:

1.) Das gewünschte Zeitrechnungssystem soll dem Menschen und der Maschine GLEICHERMASSEN dienen (habe ich aber bereits geschrieben!).

2.) An UTC stört mich nur, dass es Zeitzonen gibt, die Zeitangaben ungenau machen.

3.) "Scheiße" gehörte nicht zu meiner Wortwahl. Aber das Wort "Schwachsinn" habe ich in dem, von dir erwähnten Bezug auf's Niveau verwendet, was mir nun fast schon wieder Leid tut, da es ja in medizinischer Hinsicht eine Intelligenzminderung ausdrückt. Dies trifft natürlich nicht auf die damaligen Techniker (von denen wir sprachen) zu, aber ich hatte mir halt mehr erwartet als das Verfahren: Startzeit festlegen -> Sekunden zählen und immer und überall den Zeitstempel ins gregorianische Zeitrechnungssystem umwandeln können.

Somit sei mir also nicht böse, dass ich Contra gebe, lieber Benji. Du musst dir nämlich eingestehen, dass auch die UTC inkorrekt ist, oder hast du noch nie deine eigene Zeitzone verlassen und musstest danach deine Uhr neu stellen?

Was ich verwenden will, ist ein neuartiges Zeitrechnungssystem das kosmologisch korrekt funktioniert (Stichwort: "Erdachsenverschiebung in den letzten 2000 Jahren"), gleichzeitig in unserem tagtäglichen Leben leicht von der Lippe geht (Stichwort: "Passant fragt mich auf offener Strasse wie spät es ist und welchen Tag wir haben") und muss auch von Maschinen leicht zu verarbeiten sein. Diese drei Dinge sind mir wichtig. Mehr nicht! ;-)

Wünsche dir noch 'nen schönen Tag. Ich schaue in zirka zwei Wochen wieder rein. Greetz! --Asamaar 18:20, 13. Sep. 2008 (CEST)

Aua was hast du denn gegen Zeitzonen Asamaar, denke mal ihr seid alle ein bisschen zu sehr Computer-Nerds, Zeitzonen sind Notwendig für die Navigation, wie willst du Schlaumeier sonst den Längengrad angeben? --78.54.226.209 12:15, 27. Sep. 2008 (CEST)

Hi, User 78.54.226.209,

ich bemerke, dass "lesen" nicht gerade zu deinen Stärken gehört. Ich schrieb: "An UTC stört mich nur, dass es Zeitzonen gibt, die Zeitangaben ungenau machen." Wenn du also nicht weisst was damit gemeint ist, erklär' ich's mal: Also, wenn du von einer Zeitzone in die Nächste gehst/fährst/fliegst (was auch immer), musst du die Zeit auf deiner Armbanduhr neu stellen, nicht wahr? OK, soweit verstehst du sicher. Nun, jetzt musst du aber auch beachten, dass du die Zeit um eine Stunde vor- bzw. zurückstellst. Soweit alles klar? OK.

Was du aber anscheinend nicht bedacht hast (da du eben nur den ersten Teil meines Satzes gelesen hast), ist, dass die reale Zeit (also nicht die Gemessene auf deiner Armbanduhr) in Wirklichkeit nahtlos von Zeitzone zu Zeitzone verläuft. Die Sonne am Himmel lässt sich ja auch nicht um eine Stunde vor-/zurückstellen. Somit dürfte man in diesem Beispiel garnicht erst die Zeit verstellen, da an der Grenze zur nächsten Zeitzone weder das Eine noch das Andere stimmt. Es müsste viel mehr eine (ich nenne es mal so) "reale Zeitanpassung" stattfinden, Minute für Minute, Sekunde für Sekunde, Hundertstel für Hundertstel, usw.

Jetzt verstanden? Falls nicht, denk' mal darüber nach!

So, und nachdem ich auch weiterhin schwer mit dem Thema Zeitrechnungssystem beschäftigt bin, verzichte ich auf die Weiterführung dieser Diskussion. Was wirklich Produktives kommt hier ja leider nicht zustande. Soll jetzt nicht beleidigend sein, aber wenn man hier Probleme, wie das der Zeitzonen erklären muss, stehe ich hier bildlich am Anfang meiner Überlegungen. Soll auch nicht heissen, dass Andere dumm sterben sollen. Im Gegenteil! Ich melde mich einfach wieder, wenn ich selbst dazugelernt und das von mir angestrebte Zeitrechnungssystem gefunden habe. Vielleicht schreib' ich ja sogar ein Buch darüber. Bis dahin: Adios Amigos! --Asamaar 03:25, 16. Okt. 2008 (CEST)

Die Abschaffung/Auflösung der Zeitzonen und eine Art Rückkehr zur "echten" Zeit (also der sonnenorientierten Ortszeit) als Fortschritt zu sehen, das kann ich irgendwie nicht nachvollziehen. Jeder weiß doch, daß diese Zeitzonen mit einheitlicher Zeit innerhalb der jeweiligen Zone als Vereinfachung eingeführt wurden, um dem Menschen - um den geht es ja angeblich - das Leben zu erleichtern, weil er dann eben nicht endlos rechnen mußte, wenn er Verkehrsverbindungen dokumentierte oder sich mit entfernten Menschen auf einen gemeinsamen Zeitpunkt einigen wollte. Mit dem UNIX-Zeit-Artikel hat diese Diskussion jetzt allerdings schon lange nichts mehr zu tun. Uhrzeit ist eine willkürliche gewählte Einheit, eine Fiktion, da nimmt man einfach das, was am Bequemsten geht. 217.228.114.85 00:20, 14. Feb. 2009 (CET)

Kopenhagen-Party

Fehler unter "besondere Werte: 1000000000 ist am 9. September 2001 um 03:46:40 - aber die Party in Kopenhagen war auch um 03:46:40 - Kopenhagen ist aber UTC+1 - welcher Wert ist denn nun richtig? --91.64.58.80 14:43, 7. Jan. 2009 (CET)

Hallo liebe IP,

Dänemark ist wie Deutschland in UTC+1, sprich keine Zeitverschiebung. Was stimmt also nicht? --Benji 04:19, 8. Jan. 2009 (CET)

Verstehe ich nicht - laut Artikel startet die Zählung bei "UTC", nicht bei "UTC+1" (flapsig gesprochen), also müsste man in unserer Zeitzone doch eine Stunde später feiern. Allerdings wird das bei diesem Datum (1.9.) durch die Sommerzeit wieder ausgeglichen (oder?). 217.228.114.85 00:25, 14. Feb. 2009 (CET)

Unix-Kommandos und Beispielcode

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)

Fehler in der Tabelle Besondere Werte

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)

Bitte, korrigier es :-) --Benji 21:36, 17. Dez. 2009 (CET)

Auch der dritte Eintrag sollte ein anderes Ergebnis liefern:

 date -u -d @268435456
 Di 4. Jul 21:24:16 UTC 1978

-- Flo (nicht signierter Beitrag von 91.13.36.223 (Diskussion) 14:01, 14. Jul 2010 (CEST))

Fehler im Rechenweg-Code-Beispiel

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)

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)

ka wie das hier genau mit dem posten läuft sry falls ich was falsch mache :/

ja, der code hat definitiv einen fehler. Allerdings nicht an der obigen Stelle. J ist da richtig, denn j zählt die jahre hoch und ist dabei selbst jeweils das jahr

ein fehler ist aber bei den monaten. Denn die else bedinung wird immer genommen wenn die if bedingung falsch ist... und das ist meistens falsch.. Nämlich immer dann, wenn es garnicht um den Februar geht ;) ich habe gestern schon eine richtige version hochgeladen, aber die wurde noch nicht akzeptiert oder gecancelt, ka woran man das sieht notfalls lade ich es nochmal hoch sofern interesse besteht, denn Jb42 hat nicht unrecht (für ich schätze mal 99 von 100 Leuten wird der code nur kauderwelsch und unnötiger balast sein...selbst die hier diskutierenden verstehen ihn ja teilweise nicht einmal...trotz programmierkenntnisse) daher mein vote für löschen (nicht signierter Beitrag von 93.205.43.147 (Diskussion | Beiträge) 18:58, 24. Feb. 2010 (CET))

PI-Party

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))

Beispiel-Implementierung

Es gibt keine klassische Funktion namens "unixzeit". --Ath 12:21, 25. Jan. 2011 (CET)

Stimmt, ist missverständlich. Ich wollte mit Funktion eher ein Leistungsmerkmal ausdrücken, klingt aber zu sehr nach dem C-Terminus Funktion. Wie könnte man das ändern? Ich würde schon gern darauf hinweisen, dass diese Funktion den Rahmen der "Unixzeit" mit ihren Grenzen nicht sprengt. Der gesamte Artikel bezieht sich ja auf eine 32-Bit-Implementierung.
Grüße --Uncopy 12:39, 25. Jan. 2011 (CET)

ps: hab grad mal was probiert. --Uncopy 12:41, 25. Jan. 2011 (CET)

Nur der Abschnitt Jahr-2038-Problem bezieht sich auf eine 32-Bit-signed-Implementierung.

Für die "klassische Funktionalität" sollte der Datentyp time_t verwendet werden. Dieser ist aber nicht exakt definiert (es muss nur ein arithmetischer Datentyp sein). Der Wertebereich für das Jahr wäre abhängig von der konkreten Definition von time_t. Das würde das Beispiel unnötig kompliziert machen.

Der Datentyp long oder unsigned long hat gegenüber long long den Vorteil, dass das Beispiel für Nicht-C99-Programmierer leichter zu lesen ist. Außerdem kann es mit C++- und C89-Compilern übersetzt werden.

Der Datentyp long long hat den Vorteil das mit dem Beispiel alle Werte aus dem Abschnitt "Besondere Werte" berechnet werden können.

--Ath 13:54, 25. Jan. 2011 (CET)

Klar, die Bedeutung von long long ist mit bekannt. Allerdings bleibt die Operandenbreite in C/C++ ja völlig offen, auch wenn 10- bis 20-jährige Gewohnheit es leicht verkennen lassen. Soweit ich mich erinnere, ist kaum mehr festgelegt als dass sizeof(short) ≤ 1 ist und sizeof(short) ≤ sizeof(int) ≤ sizeof(long). So denke ich inzwischen, mit einem Beispiel in einer anderen Sprache wäre uns allen vermutlich besser gedient.
Beste Grüße --Uncopy 10:58, 3. Feb. 2011 (CET)

Neben o.g. Kritik am Beispiel-Quelltext möchte ich anmerken, dass es tatsächlich nicht mit dem Verbreitern der Datentypen getan ist. Sollte man die (Beispiel-)Funktion tatsächlich in ihrer Gültigkeit auf Milliarden von Jahren ausweiten wollen, hätte man die Magic Numbers 4, 100 und 400 einem kritischen Blick zu unterziehen. Inwieweit diese nämlich stimmen, ist keineswegs trivial.
Grüße --Uncopy 23:13, 8. Feb. 2011 (CET)

Unix-Uhr in Hundertstel Sekunden

"Vor Unix Version 6 zählte die Unix-Uhr in Hundertstel Sekunden, daher musste die Epoche jedes Jahr neu festgelegt werden. " - warum? Und was ist die Epoche? Habe den Satz mal rausgenommen, bitte erst nach Erläuterungen wieder einfügen (nicht signierter Beitrag von 213.30.216.205 (Diskussion | Beiträge) 10:27, 16. Feb. 2011 (CET))

Was die Epoche ist, steht im ersten Absatz:

Dieses Startdatum wird auch als The Epoch (siehe Epoche) bezeichnet.

Und damit ist doch alles klar, oder? Jedes Jahr wurde die "Epoche" wieder auf den 01. Januar gelegt und der Variablenzeitwert auf 0 gesetzt. --Benji 19:03, 19. Feb. 2011 (CET)

Und weil dies so war, konnten Backupbänder von UNIX Versionen vor UNIX V6 (Für das UNIX Restaurations Projekt) teilweise auch nur durch Dennis Ritchie an Hand des verwendeten C-Dialekts in die richtige Epoche eingeordnet werden.--Schily 19:25, 19. Feb. 2011 (CET)

"31.12.1969"-Bug

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)

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)

Doodle zur Unixzeit 1234567890

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)

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)

Danke. Ich habe den Link ergänzt. --Eddie 14:24, 7. Jan. 2012 (CET)

Zeitstempel in einer Gleitkommazahl - so ein Unsinn

"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)

Falscher Wert in Tabelle?

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))

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)

1333333337 Erklärung

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)

Moin, dem Bearbeitungskommentar nach wohl ersteres – ist das ein sinnvoller Eintrag? --El Grafo _(COM) 18:18, 5. Mär. 2012 (CET)

1333333337 4F 79 0D 59 2. April 2012 02:22:17

1342177280 50 00 00 00 13. Juli 2012 11:01:20

1400000000 4F 79 0D 59 13. Mai 2014 16:53:20 korregiert das mal richtig,...das ist ein auffälliger copy-paste-fehler Sivicia (Diskussion) 22:19, 14. Okt. 2012 (CEST)

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)

habe es gelöscht --Carl B aus W (Diskussion) 17:10, 17. Feb. 2013 (CET)

Schaltsekunde

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)

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)

Wahl des Datums

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) (ohne Benutzername signierter Beitrag von 46.5.16.82 (Diskussion))

Zählung via 64-Bit-Zahl

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)