PureBoard

> Man vergisst das ja heute leicht.
mir ist das noch wohlbekannt. ich hatte in den 80ern mit Datensätzen zu tun,
in denen die Jahreszahl aus Platzgründen zweistellig abgelegt war.
das ist ja die eigentliche Ursache der y2k-panik, das weiß kaum noch jemand.

es gibt nicht nur uralte frösche

@LittleJohn:
Sau gut!

Da gibt es keine Fehler. Sogar im Jahr 10000 ist noch alles richtig!

Könnte ich mit '#DAYS_UNTIL_1970_01_01' auch einfach das Offset
verschieben um z.B. im Jahre 1500 anzufangen?

Warum frag ich eigentlich? Ich probiers mal aus.

///Edit:
Okay, klappt wunderbar.

Aber mal eine Frage an alle: Meldet sich bei euch beim Ausführen auch
immer Avira Antivir mit einem Trojanischen Pferd? Das ist nur bei diesem
Datumscode so. Bei anderen Programmen nicht. Bei Stargates Version
war es auch so.

bitte vergib mir, wenn ich das jetzt nicht anteste...

ich ärger mich seit gut 24h damit rum, dass AVAST das Game "Lost Castle" von Reiner Prokein anmeckert.
ich bekomme nicht mal den Download vollständig.

...also, auf noch nen Fehlalarm hab ich grad gar keine Zeit, sorry.

... aber grundsätzlich sollte man das problem wohl mal eingrenzen, denke ich...

NicTheQuick hat geschrieben:@LittleJohn:
Sau gut!

Danke!

NicTheQuick hat geschrieben:Könnte ich mit '#DAYS_UNTIL_1970_01_01' auch einfach das Offset
verschieben um z.B. im Jahre 1500 anzufangen?

Warum frag ich eigentlich? Ich probiers mal aus.

///Edit:
Okay, klappt wunderbar.

Kurze Antwort:
Ja, mit allen Offsets >= 0 sollte es klappen.

Lange Antwort:
Ob's auch mit negativen Offsets geht weiß ich nicht, das müsste ich genauer prüfen bzw. gegebenenfalls den Code ändern.
Und natürlich liefert Date() für ein Datum nach 1970 einen größeren Wert wenn 1500-01-01 = 0 gesetzt wird, als wenn 1970-01-01 = 0 gesetzt wird. Dadurch wird eher die Grenze des Wertebereichs für Quad erreicht. Allerdings sollte der Spielraum für normale Zwecke ausreichen. Z.B. auf der Basis von 1970-01-01 kann man Datumsangaben bis 04.12.32548, 15:30:07 bearbeiten. Wir treffen uns dann zum Tee, OK?

Was ich noch nicht ausdrücklich erwähnt hatte ist, dass die Berechnung auf dem Gregorianischen Kalender basiert. Der wurde ja erst 1582 eingeführt ... Aber wenn man nicht präzise historische wissenschaftliche Berechnungen durchführen will, kann man meist einfach so tun als wenn er auch schon vorher gegolten hätte. Wenn man den Wechsel zum Gregorianischen Kalender aber exakt berücksichtigen will, dann wird's wirklich schwierig. Denn er wurde nicht in allen Ländern zur gleichen Zeit eingeführt. So kann z.B. die Angabe "3. Januar 1602" je nach dem Land auf das sie sich bezieht, eine Angabe nach dem Gregorianischen Kalender sein oder auch nicht. Laut Wikipedia wurde der Gregorianische Kalender in China sogar erst am 1. Januar 1929 eingeführt. Aber mit solchen Sachen möchte man sich eigentlich nicht wirklich beschäftigen.

NicTheQuick hat geschrieben:Aber mal eine Frage an alle: Meldet sich bei euch beim Ausführen auch
immer Avira Antivir mit einem Trojanischen Pferd? Das ist nur bei diesem
Datumscode so. Bei anderen Programmen nicht. Bei Stargates Version
war es auch so.

Das ist interessant. Ich selbst kann nur sagen, dass das hier mit AVG 8 nicht passiert.

Gruß, Little John

Moment mal.

Wieso kommt da bei was falsches raus? 'DateQ()' scheint zu funktionieren, aber 'SplitDateQ()' nicht.

NicTheQuick hat geschrieben:Moment mal.

Wieso kommt da bei was falsches raus?

Gute Frage.

In meinem Beitrag mit dem Code sind ja auch umfangreiche Tests enthalten, auch der Test den Du hier machst. Der Test wurde neulich bestanden (auch bei Dir, nicht wahr?). Und wenn ich jetzt direkt den Code aus meinem Posting hier im Thread herauskopiere, liefert Dein neuer Test damit erwartungsgemäß Du hattest ja im Code zwischenzeitlich mal den Datums-Offset geändert. Sonst nichts?
Kopier bitte den Code nochmal "frisch" hier aus dem Forum, und wiederhole damit den aktuellen Test. Was kommt dann 'raus?

Gruß, Little John

Nein, ich habe den Original-Quellcode genommen.
Vielleicht liegt es aber auch daran, dass nach Klick auf "Ausführen" zuerst
zweimal der Virus TR/Crypt.XPACK.Gen gefunden wird und ich zuerst mal
auf "Ignorieren" klicken muss.

Das komisch ist: Der Virus scheint jetzt auch in mehreren anderen
PureBasic-Programmen zu sein, die ich entweder frisch kompiliere oder
schon seit Jahren in kompilierter Form vorliegen habe. Andere
EXE-Dateien sind nicht betroffen.

Ich hab' eben mal mit einer der angeblich betroffenen Dateien den
Kaspersky Online Scanner gefüttert und der hat kein Problem mit der
Datei.

Scheiß AntiVir!
Ich schmeiß den gleich runter...

Aber zurück zum Code.
Ich hab AntiVir mal ausgeschaltet und das Datum ist immer noch falsch.
Es kann doch nicht daran liegen, dass ich den Code mit PB V4.00 teste,
oder?

Ich werde gleich mal V4.20 testen und mich dann wieder melden.

///Edit 1:
Nein, sogar in der Original-IDE und mit PB 4.20 gibt es den Fehler.

Das kann doch nicht sein.

///Edit 2:
Uff! Hatte bist eben noch V4.20 beta auf meinem Windows-PC. Hab jetzt
auf V4.20 geupdated und siehe da. Jetzt stimmt das Datum!

Vielleicht kann ja mal jemand den Code auf V4.00 oder V4.20 beta testen
und bestätigen, dass er dort falsch funktioniert. Sonst bin ich jetzt noch
verwirrter als vorher.

///Edit 3:
Hier also das ganze nochmal als "Klasse".
common.pbi
Object.pbi
Date.pbi

Warum ich mir die Mühe gemacht habe?
Weil ich es so leichter in meinem Projekt verwenden kann.

Danke nochmal an alle Vorposter!

Auf´m Laptop habe ich noch 4.10 und dort tritt der Fehler auch auf!

Gruß
Helle

Hmm... keine Ahnung, warum das mit älteren Versionen nicht funktioniert. Ich hab jetzt im Quellcode dazugeschrieben, dass es mit Versionen vor 4.20 final Probleme gibt.

Gruß, Little John