Domino 9 und frühere Versionen > ND7: Entwicklung

Schaltjahr - Was ist mit dem Jahr 1700 los ??

(1/3) > >>

eknori:
2008 ist ja wieder einmal ein Schaltjahr. Um das zu überprüfen, habe ich eine kleine Funktion zusammengebaut:


--- Code: ---Function IsLeapYear ( y As Integer ) As Boolean

IsLeapYear = True
Set dt = New NotesDateTime( Datenumber( y ,3, 1) )
Call dt.AdjustDay (-1)
If Not Day (dt.DateOnly) = 29 Then
IsLeapYear = False
End If

End Function
--- Ende Code ---

Die Funktion erstellt ein Notes DateTime object und setzt das Datum auf den 1.3. des Jahres, das als Parameter übergeben wird. Danach zieht es von diesem Datum 1 Tag ab, um auf den letzten Tag des Monats Februar zu gelangen.
Ist der Wert des Tages 29, dann ist es ein Schaltjahr, sonst nicht.

Ich habe dann mal ein wenig mit der Funktion rumgespielt und habe mal die Zahl 1700 eingegeben. WUMMS ... Fehlermeldung.
1699 und 1701 sind kein Problem, aber das Jahr 1700 ...

In einer Schleife habe ich dann die Jahreszahlen 1 bis 9999 an die Funktion übergeben. Insgesamt erhalte ich 6 mal die gleiche Fehlermeldung wie beim Jahr 1700.

1700, 1500, 1400, 1300, 1100 und 1000

Nicht, daß da irgendwie ein Bug in Notes ist  ;D

koehlerbv:
Witzig  ;D

Regelrecht kritisch wird es aber, wenn man Deinen Code ein ganz klein wenig abändert:
[snip]
   y = 1700
   
   Set dt = New NotesDateTime (Datenumber (y, 3, 1))
   Call dt.AdjustDay (-1)
   If Left$ (dt.DateOnly, 2) = "29" Then
      Print "Schaltjahr: " & Cstr (y)
   End If
[/snip]

Dann IST 1700 ein Schaltjahr. Zumindest bei IBM Lotus  ;D

Bernhard

PS: Interessanterweise sind die kritischen Jahre alle vor der Gründung der USA. Soll uns das etwas sagen?

Glombi:
Interessant. Notes scheint einige Schierigkeiten mit dem Mittelalter zu haben:

Error: 'Unable to interpret time or date' when entering specific dates from the year 1752

Andreas

koehlerbv:
Äh, nö, Andreas. Das ist schon in Ordnung - das sind die Tage, die es durch den Wechsel der Kalender vom ganz ollen Julius zu dem vom ollen Gregor wirklich futsch sind. Aber ... Siehe unten!

Es scheint aber so, dass Notes vor dem 13.09.1752 mit dem Julianischen Kalender weiterrechnet (und ja - der hatte andere Schaltjahre!). Nur: Das darf zu keiner Fehlermeldung führen (es ist auch nicht ersichtlich, warum es bei Ulrichs "Fundstellen" zu type mismatches kommt!).

Weiters: Der Gregorianische Kalender wurde in Europa (und in den von europäischen Ländern jeweils beherrschten Gebieten) zu ganz unterschiedlichen Zeiten eingeführt. Start war im Vatikan: Dem 04.10.1582 folgte der 15.10.1582. ACHTUNG: Dabei änderten sich auch die Wochentage. Was macht da eigentlich (@)Weekday?
Die angloamerikanischen Ländern / Kolonien pennten dann erstmal 170 Jahre weiter julianisch. Okay, die Russen trieben es noch ärger  ;D

Eigentlich müsste daher jede Länderversion von Notes / Domino andere Wechselpunkte berücksichtigen. Aber da sind die Amis eben stur. Obwohl sie doch damals spät dran waren ...

Bernhard

CarstenH:
Moin =)

Nachdem ich da gestern noch etwas rumprobierte habe ich vermutlich die Ursache für den type mismatch gefunden:

Habe mir als Beispiel jetzt nur das Jahr 1700 rausgenommen, für andere Jahre passiert das aber auch ^^

Die Klasse NotesDateTime stellt keine reine LotusScript Klasse dar. Vielmehr ist es eine Klasse, die Konvertierungen zwischen Script und Formelsprache ermöglicht. Ulrich hantiert hier also (gewollt oder ungewollt) mit 2 Programmiersprachen.

Und jetzt kommt der Clou - LotusScript und Formelsprache scheinen jeweils eigene Datumsroutinen zu besitzen statt einer, auf die von beiden Seiten zugegriffen wird. Und eine von beiden rechnet falsch *g*

Während LotusScript sehr wohl weiss, dass 1700 kein Schaltjahr war ist die Formelsprache (und damit das gesamte Front- und Backend des Designers) da anderer Meinung.

Den 1.3.1700 kennen beide Sprachen. So weit so gut. Wenn man jetzt per Script 1 Tag abzieht entsteht ein "unmöglicher Wert" (daher der type mismatch). Die ScriptProperty sagt es muß der 28.2.1700 sein, was ja auch korrekt ist. Die Formelproperty behauptet aber es muß der 29.2.1700 sein - Bingo: Error.

Habs nochmal mit reiner Formelsprache in einer Maske nachgestellt, da kommt kein Fehler - aber dafür auch der nicht existierende 29.2.1700.

Im angehängten Screenshot kann man übrigens wunderbar sehen wie ein und das selbe Datum 3 Werte gleichzeitig hat, 2 wären korrekt. Wenn man mit (europäischer) Zeitzone den 1.3.1700 einstellt so müßte die GMT Zeit auch ohne 1 Tag manuell abzuziehen am Tag davor liegen, das tut sie auch, nur eben unterschiedlich für Script und Formelsprache.

Ist also definitiv ein Fehler - egal für welchen Kalender welches Pabstes oder Zaren man sich entscheidet sollte Notes hier wenigstens überall gleich falsch bzw. richtig rechnen und nicht mal so und mal so.

Gruß, Carsten

Navigation

[0] Themen-Index

[#] Nächste Seite