Warum beginnen Datumsbereiche in der Datenverarbeitung in alten Zeiten?

484
svbnet

Beim Wikipedia-Artikel für HFS + habe ich festgestellt, dass der zulässige Datumsbereich vom 1. Januar 1904 bis zum 6. Februar 2040 ist. Ebenso ist der Bereich für NTFS vom 1. Januar 1601 bis zum 28. Mai 60056. In meinen Augen ist das lächerlich Ich kann mir keine Fälle vorstellen, in denen für eine Datei ein Änderungsdatum erstellt werden muss, das in den 1600er oder 1900er Jahren festgelegt wurde. Ich kann die Unix-Zeitstempel-Epoche verstehen, da es vernünftig wäre, eine Datei in den 70ern, 80ern usw. erstellt / modifiziert zu haben, aber es scheint nur unlogisch, die Epoche dieser Zeitstempel so weit in die Vergangenheit zu setzen.

-1
http://stackoverflow.com/questions/10849717/what-is-the-ignificance-of-january-1-1601 Polygnome vor 7 Jahren 4
Dies liegt an dem 400-Jahres-Zyklus für Sprungintervalle und an der Modulo-Arithmetik, die in der Mathematik rund um die Sprungzyklen beteiligt ist. Es ist der Beginn der ersten solchen Periode, in der digitale Dateien entstanden sind. Frank Thomas vor 7 Jahren 2
Es ist bemerkenswert, dass ANSI das gleiche Datum für ihre Stempel übernommen hat, also in den COBOL- und anderen ANSI-Sprachspezifikationen verwendet wird. Grundsätzlich ist es sehr viel einfacher, den Rohwert zu berechnen. Dies ist um einiges einfacher, wenn Sie die Anzahl der Rekursionen im Hinblick auf Zeitanpassungszyklen begrenzen können, indem Sie eine Basis festlegen, von der wir uns nicht zu weit entfernt haben (im großen Schema von Dinge). Wenn Sie jemals versucht haben, Code zu schreiben, um das Datum zu berechnen, an dem der Ostersonntag angezeigt wird, werden Sie feststellen, dass je weiter Sie vorwärts oder rückwärts gehen, desto länger und komplizierter wird die erforderliche Formel. Frank Thomas vor 7 Jahren 0

3 Antworten auf die Frage

2
Jamie Hanrahan

Es ist nicht nur NTFS; Die interne Windows-Zeitmessung erfolgt im gleichen Zeitformat und mit demselben Beginn der Epoche.

Sie wussten, dass sie einen binären 64-Bit-Zeitwert wollten, da der ursprüngliche Unix-32-Bit-Wert bereits als Sackgasse bekannt war (diese Zähler werden 2038 umbrochen) und 64-Bit-Zeitwerte wurden bereits in VMS verwendet. 64 Bits geben die Möglichkeit, etwa 18 Milliarden Milliarden verschiedene Zeitwerte zu berechnen. Nun, eigentlich nur 9 Milliarden Milliarden, weil Zeitwerte mit dem hohen Bitsatz in Windows (wie in VMS) eine andere Bedeutung haben. Wir haben also "nur" 63 Bits, um Datum und Uhrzeit zu zählen.

Während die 32-Bit-Unix-Zeit nur Sekunden gezählt hat, rechnet Windows-Zeitstempel in Schritten von 100 Nanosekunden. Ein Zeitwert von 1 bedeutet also 100 ns nach Mitternacht am 1. Januar 1601.

Aber wieso ein so "historisches" Datum wählen?

Nun, erstens macht es Wochentage und ähnliche Berechnungen etwas einfacher, da dies das erste Jahr des frühesten 400-Jahres-Zyklus war, in dem elektronische Computer jeglicher Art enthalten waren. Aus diesem Grund gibt es einige sehr autoritative Unterstützung .

Ich muss jedoch davon ausgehen, dass im Zusammenhang mit der modernen Berechnung die zusätzliche Rechenleistung, die erforderlich ist, um ein anderes Startjahr zu bewältigen, relativ gering ist.

Der 1. Januar 1601 ist auch der Tag, an dem die ANSI-Daten gezählt werden. Das "Windows-Datum" ist also dieselbe Tagesnummer wie das "ANSI-Datum", was die Sache an verschiedenen Stellen etwas einfacher macht.

Es wurde auch als "Jahr 1" des Gregorianischen Kalenders standardisiert (obwohl dieser Kalender damals nicht überall angenommen wurde).

Aus praktischen Gründen sollte jedoch Folgendes beachtet werden: Dieses Datums- / Zeitformat ermöglicht die Darstellung historischer Datumsangaben in z. B. Datenbanken neben heutigen, wobei das gleiche Format verwendet wird. Eine genealogische Datenbank kann beispielsweise die Geburts- und Sterbedaten Ihrer Vorfahren von über 400 Jahren speichern, was weitaus länger ist, als die meisten dieser Aufzeichnungen in zuverlässiger Form vorliegen.

Es hätte keinen Sinn gehabt, dies früher auszudehnen, beginnend mit dem Jahr 1201 oder sogar mit dem Jahr 1, da der Übergang vom Juli zum Gregorianischen Kalender in einigen Ländern 1582 begann und erst 1926 andauerte, je nachdem, in welchem ​​Land Sie sich befanden waren. Alle Daten, die im ANSI-Zeitformat und im Windows-Format "binär" aufgezeichnet wurden, werden als gregorianischer Kalender angenommen.

Übrigens, VMS verwendet ein ähnliches Schema, aber seine Basiszeit ist der 17. November 1858. Dies war ein Standard, den das Smithsonian Astrophysical Observatory als "Basisdatum" für die Satellitenverfolgung auswählte; Dies bezog sich auf die frühere Nutzung des ursprünglichen Julianischen Tagesplans durch die Astronomen, der seit dem 1. Januar 4713 (Mittag), dem 1. Januar 4713 v. Durch die Verwendung des MJD anstelle des JD konnten sie zeitgenössische Datumsangaben in nur 18 Bit anpassen, was zu dieser Zeit eine wichtige Leistung war. Weitere Informationen finden Sie in diesem Artikel von VMS Engineering.

1
Aganju

Datumsangaben (und deren Formatangaben auf Bitebene) werden nicht nur zum Beschriften von Dateien, sondern auch zur Berechnung und an vielen anderen Stellen verwendet. Ein Historiker möchte in seinen Excel-Spalten beispielsweise Datumsangaben aus dem 17. oder 18. Jahrhundert haben; oder ein Astronom berechnet in diesen Zeiträumen die Ausrichtung der Planeten.

Selbst wenn die Anzahl der Leute, die davon Gebrauch haben, gering ist, ist der Verlust fahrlässig - es spielt keine Rolle, ob Sie dieses Format für 100, 5000 oder 60000 Jahre verwenden können. es wird die nächsten 50 Jahre wahrscheinlich nicht überleben.

"Es wird wahrscheinlich die nächsten 20 Jahre nicht überleben." Das ist ein bisschen pessimistisch. Warum glaubst du das? DavidPostill vor 7 Jahren 0
Nicht, weil es schlecht ist oder irgendetwas, aber bessere Dinge werden mitkommen. Wenn Sie sich die derzeitige Geschwindigkeit beim Erhöhen der Größe ansehen, wird Terabytes in 20 Jahren die normale Größe für Dateien sein. Ich bin bereit, es auf 50 zu ändern, mein Punkt war nicht Tausende von Jahren Aganju vor 7 Jahren 0
@ Arganju, ich glaube, Sie unterschätzen die Menge an COBOL, die noch auf Mainframes läuft. Beachten Sie auch, dass sie für hochstufige Programme wie Excel beliebig beliebiges Hintergrund- und Präsentationsformat für Datumsangaben implementieren können. Das Thema hat also wirklich wenig mit Userland-Programmen zu tun, sondern mit den einfachen Mechanismen des Dateisystems. Sachen, die auf der Linie zwischen Software und Hardware liegen. Es gibt eine Menge Zahlentheorie auf dieser Ebene; Viele kluge Leute haben jahrelang extrem effiziente und clevere Algorithmen entwickelt. Frank Thomas vor 7 Jahren 0
Und das Format / die Konvention, Jahre als zweistellige Ganzzahl zu speichern, wird wahrscheinlich nach 1990 nicht überleben ... oh, warte ... :-) ⁠ G-Man vor 6 Jahren 0
1
LMiller7

Bei einer isolierten Untersuchung kann der breite Zeitstempelbereich von NTFS unlogisch erscheinen. Aber wenn man das Gesamtbild betrachtet, ist es völlig logisch.

Ein Betriebssystem bietet unter anderem Funktionen, die die meisten Programme benötigen. Dadurch können sich Programmierer auf ihre Programme konzentrieren, anstatt diese allgemeinen Funktionen für jedes Programm neu zu schreiben. Ein Betriebssystem, das diese Funktionen nicht bietet, ist unwahrscheinlich. Windows und Linux bieten Hunderte solcher Funktionen.

Windows enthält eine Reihe von Funktionen zum Darstellen und Arbeiten mit Datum und Uhrzeit. Für maximale Nützlichkeit deckt dies einen möglichst breiten Bereich von Daten ab. Viele Programme verwenden diese Funktionen für eine Vielzahl von Zwecken.

Das NTFS-Dateisystem wurde als Teil der NT-Plattform veröffentlicht. Wie bei jedem modernen Dateisystem waren Dateistempel erforderlich. Logischerweise entschieden sich die Entwickler dafür, dasselbe System zu verwenden, das den Anwendungen zur Verfügung gestellt wird. Dies macht es für Entwickler einfacher. Natürlich ist der Datumsbereich viel größer als für Datumsstempel erforderlich, kostet aber nichts und verursacht keine Probleme. Die Verwendung eines anderen Systems mit einem engeren Datumsbereich für Datumsstempel wäre unlogisch gewesen.

Verwandte Probleme