„Signierte int32 Variable“

[bifi]

„Signed int32“ heißt nicht „signiert“ sondern „mit Vorzeichen“…

Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf schütteln. Man hätte ja wenigstens ein uint32 nehmen können. Dann hätte man zumindest his 2042 seine Ruhe gehabt. Auch wenn das Konzept an sich weiterhin bekloppt ist.



1 mal bearbeitet, zuletzt am 02.01.22 11:16 durch bifi.

[bifi]

Steht sogar im verlinkten Doku-Artikel von Microsoft:
„ Stellt eine 32-Bit-Ganzzahl mit Vorzeichen dar.“

;)

[LH]

bifi schrieb:
--------------------------------------------------------------------------------
> Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise
> auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf
> schütteln. Man hätte ja wenigstens ein uint32 nehmen können. Dann hätte man
> zumindest his 2042 seine Ruhe gehabt. Auch wenn das Konzept an sich
> weiterhin bekloppt ist.

Erinnert mich aber doch sehr an das Problem mit den Unix-Timestamps:
https://en.wikipedia.org/wiki/Year_2038_problem

[Profi_in_allem]

int32 reicht 68 Jahre = 1970 + 68 = 2038. Bei einem Exchange 2013, 2016 & 2019 besteht also gar keine Notwendigkeit hier umzustellen, da die Server niemals solange laufen werden. Soviel zum Fachkräftemangel auf golem.

Da ich IT-Profi bin und überaus intelligent, zählt meine Meinung mehr als alle anderen. Dies begründe ich ganz einfach, meine Meinung ist immer gut durchdacht, ich habe also einen Denkvorsprung vor allen anderen. Ich bitte dies bei etwaigen Antworten auf meine Posts zu bedenken, ich habe und hatte bisher immer Recht. Wer also anderer Meinung ist wie ich, sollte vorher bedenken, dass er höchstwahrscheinlich im Unrecht ist.



2 mal bearbeitet, zuletzt am 02.01.22 11:25 durch Profi_in_allem.

[ad (Golem.de)]

bifi schrieb:
--------------------------------------------------------------------------------
> „Signed int32“ heißt nicht „signiert“ sondern
> „mit Vorzeichen“…


So ist es.
>
> Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise
> auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf
> schütteln. Man hätte ja wenigstens ein uint32 nehmen können. Dann hätte man
> zumindest his 2042 seine Ruhe gehabt. Auch wenn das Konzept an sich
> weiterhin bekloppt ist.

Keiner weiß es, nennt man halt Fehler.

[bifi]

Vermutlich hat einer rumgebastelt bis er was gefunden hat, was irgendwie den Zweck erfüllt. Und niemand hat ein Code-Review gemacht. :)

Dabei wurde dann übersehen zu prüfen: was passiert, wenn…

[LH]

Profi_in_allem schrieb:
--------------------------------------------------------------------------------
> int32 reicht 68 Jahre = 1970 + 68 = 2038

Wenn man die Sekunden seit 1970 zählt, was aber hier wohl nicht gemacht wurde. In diesem Ansatz hat man wohl das Datum als Zahl direkt gespeichert, in einer Form wie z.B. YYMMDDHHMMSS

[Tuxee]

Nur dass dieses "Problem" seit Jahren bekannt und bewusst ist und Lösungen ausgearbeitet wurden und werden. (Dass irgendwelche ranzigen embedded Systeme in 16 Jahren ins Schwitzen kommen werden? Damit muss man leben.)

[Cybso]

bifi schrieb:
--------------------------------------------------------------------------------
> Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise
> auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf
> schütteln.

Diese Art, Datum und Zeit zu speichern, findet man häufig in Datenbanken aus dem 90ern. Hat den Vorteil, dass man es direkt eingeben, lesen und drucken kann. Da war 2022 allerdings auch noch in weiter Ferne :-)



2 mal bearbeitet, zuletzt am 02.01.22 11:39 durch Cybso.

[LH]

Tuxee schrieb:
--------------------------------------------------------------------------------
> Nur dass dieses "Problem" seit Jahren bekannt

Nur weil ein Problem bekannt ist, wird es leider nicht automatisch auch korrigiert. Auch das Y2K Problem war bereits viele Jahre vorher bekannt, aber am Ende wurde es leider oftmals erst recht Zeitnah gelöst. Oftmals ist der Druck eben nicht groß genug, um alte Systeme zu korrigieren. Und aktuell gibt es durchaus noch nagelneue Embedded-Systeme, die von Werk aus anfällig für dieses Problem sind.
Zudem müssen Embedded-Systeme gar nicht bis 2038 aktiv sein, um Probleme zu verursachen, es gibt viele Situationen, in denen zukünftige Datumswerte eine Rolle spielen. Dazu nennt auch der WP-Artikel einen Fall bei AOL als Beispiel.

Auch ich glaube nicht an einen weltweiten Ausfall, aber dennoch ist es ein Problem und kein "Problem".

[LH]

Cybso schrieb:
--------------------------------------------------------------------------------
> Diese Art, Datum und Zeit zu speichern, findet man häufig in Datenbanken
> aus dem 90ern. Da war 2022 allerdings auch noch in weiter Ferne :-)

Man unterschätzt zuweilen, wie lange die eigene Software im Einsatz ist. Einiger meiner Entwicklungen aus dem Jahr 2000 sind heute noch bei Firmen mit relativ wenigen Änderungen im Einsatz. Das ist etwas grusselig, da damit natürlich auch viele Korrekturen fehlen, aber so ist die Realität eben. Was läuft wird selten angefasst.

[mibbio]

Profi_in_allem schrieb:
--------------------------------------------------------------------------------
> da die Server niemals solange laufen werden. Soviel zum Fachkräftemangel auf golem.

Da würde ich mich jetzt nicht unbedingt drauf verlassen. Die Support-Zeiträume der jeweiligen Versionen sind zwar ein Anhaltspunkte, bis wann man es maximal betreiben sollte, nur wird es vereinzelt halt trotzdem darüber hinaus verwendet, so lange es grundsätzlich funktioniert und kein nennenswerter Leidensdruck entsteht.

Die Bundesregierung bzw. die Ministerien haben wohl vereinzelt immer noch Windows Server 2003 und sogar Debian 3.1 im Einsatz*, was schon seit bis zu 12 Jahren aus dem (erweiterten) Support ist. Das dürften sicherlich nicht die einzigen Fälle sein, wo noch tickende Software-Zeitbomben im Einsatz sind.

* https://media.ccc.de/v/rc3-2021-chaoszone-358-inside-bundestag

[Knuspermaus]

Zumeist werden in bzw. für Behörden Softwarestrukturen geschaffen, die nur für einen bestimmten Zeitraum gedacht ist... eine Notlösung quasi.
Leider bleibt dann die Beauftragung für die eigentliche Softwarelösung für die geschaffene Struktur aus, so das aus der Notlösung eine Dauerlösung etabliert wird, weswegen jetzt auch einige Gesetze geändert wurden.

(viele ältere Links sind mittels Leerzeichen deaktiviert, da ich bis vor kurzem noch keine Posten durfte)
Alles was ich schreibe ist meine persönliche Meinung. Nicht immer gebe ich dem Leser genehme Quellen an.

[apoth90]

bifi schrieb:
--------------------------------------------------------------------------------
> Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise
> auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf
> schütteln.

Dass ein uint geholfen hätte sehe ich eigentlich mehr als Zufall an. Der wesentliche Fehler bestand darin, einfach Ziffern in einen Integer zu schreiben, ohne zu wissen, wie die interne Darstellung funktioniert.

[bifi]

apoth90 schrieb:
--------------------------------------------------------------------------------
> Dass ein uint geholfen hätte sehe ich eigentlich mehr als Zufall an. Der
> wesentliche Fehler bestand darin, einfach Ziffern in einen Integer zu
> schreiben, ohne zu wissen, wie die interne Darstellung funktioniert.


Deswegen auch:
„Man hätte ja wenigstens ein uint32 nehmen können. Dann hätte man zumindest his 2042 seine Ruhe gehabt. Auch wenn das Konzept an sich weiterhin bekloppt ist.“

;)

[countzero]

Cybso schrieb:
--------------------------------------------------------------------------------
> bifi schrieb:
> ---------------------------------------------------------------------------
> -----
> > Wie man auf die Idee kommen kann einen Zeitwert auf diese Art und Weise
> > auch noch in einem sint32 abzuspeichern... da kann man nur den Kopf
> > schütteln.
>
> Diese Art, Datum und Zeit zu speichern, findet man häufig in Datenbanken
> aus dem 90ern. Hat den Vorteil, dass man es direkt eingeben, lesen und
> drucken kann. Da war 2022 allerdings auch noch in weiter Ferne :-)

SAP macht das immer noch so :-)
OK, nicht genauso, sie waren immerhin so schlau und haben statt eines INT ein CHAR(8) genommen und da dann YYYYMMDD reingeschrieben, sodass sie bis zum 31.12.9999 auf der sicheren Seite sein sollten ;-)
Dafür waren sie bei der Sprache nicht so vorausschauend und haben nur ein Zeichen vorgesehen, D für Deutsch und E für Englisch ging ja noch, aber irgendwann sind ihnen halt doch die Buchstaben ausgegangen. Grade mal geschaut, Zahlen sind sie auch schon durch und mittlerweile beim Kleinbuchstaben i angekommen.

[minnime]

Es wäre auch gegangen wenn man das Jahr andersrum geschrieben hätte, also nicht 2201 sondern 1022. So ganz ist mir das Prinzip dieses Datumsformats noch nicht klar.

[ayngush]

Das ist ja auch eigentlich kein Datumswert, sondern eine vom Datum abgeleitete Versionsnummer einer Signaturdatei der betroffenen Malware Engine, die da verglichen werden soll.
Der „very Hotfix“ besteht ja seitens Microsoft ja wohl auch darin den Dezember 2021 zu verlängern auf den 33.12. usw.

[mambokurt]

ayngush schrieb:
--------------------------------------------------------------------------------
> Der „very Hotfix“ besteht ja seitens Microsoft ja wohl auch
> darin den Dezember 2021 zu verlängern auf den 33.12. usw.

Das sind ein paar Füchse bei Microsoft, sagste nix.

[Thargon]

Schon großartig wenn die Sinnhaftigkeit eines Datumsformats von der Basis 10 abhängt. Bei so einer "Methodik" vermute ich, dass die Code-Reviewer vor der Frage standen, ob man zig Personenmonate in eine Neuentwicklung steckt, oder das eben so durchwinkt. Dann haben Agenda und Ökonomen entschieden :)
Zum Glück haben wohl alle Betriebe, die Exchange einsetzen auch sicherlich noch Faxgeräte in Einsatz.