Schaltjahr - Was ist mit dem Jahr 1700 los ??

[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

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 

[koehlerbv]

Witzig 

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 

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 

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

[eknori]

Carsten, Danke für deine Bemühungen und die Erklärung.

[koehlerbv]

Naja, das mit den "Konvertierungen zwischen LS und Formelsprache" würde ich jetzt nichts so sehen.
Beide Sprachvarianten greifen ja auf die Notes-API zurück, aber die NotesDateTime class ist einfach ... komisch.
Deine Beobachtungen im Debugger weisen daher genau auf den Kern.
Mehr dazu auf dem EntwicklerCamp. Und ich brauche die Klasse de facto überhaupt nicht.

Ich greife jetzt mal dem EntwicklerCamp voraus. Wenn wir auf die NotesDateTime class verzichten, dann sieht der Code so aus:

Code

Sub Click (Source As Button)
	
	Dim iYear As Integer
	Dim vDate As Variant
	
	On Error Goto ErrorRoutine
	
	iYear = 1700
	
	vDate = Datenumber (iYear, 3, 1)
	vDate = vDate - 1
	
	If Day (vDate) = 29 Then
		Print "Schaltjahr: " & Cstr (iYear)
	Else
		Print "KEIN Schaltjahr: " & Cstr (iYear)
	End If
	
	Exit Sub
	
ErrorRoutine:
	Call ErrorHandler ("Button")
	Exit Sub
End Sub

Und schon klappt es mit dem Nachbarn. 
Ich tippe: Der Wrapper für die Klasse (und für @functions, aber das habe ich selbst noch nicht getestet - das hat ja Carsten schon gemacht - DANKE!) hat einen Schuss.

Bernhard

PS: Ich habe diese Tests übrigens zuerst unter Notes R5.0.8 gemacht. Das Thema ist also nicht neu 

[flaite]

Beide Sprachvarianten greifen ja auf LS zurück, aber die NotesDateTime class ist einfach ... komisch.

Wieso das? Imho ist beides in C implementiert. Formelsprache war ja auch eher da.


Ich vermute, die haben einfach Schaltjahr-Regel 2 des gregorianischen Kalenders vergessen.

    * Alle Jahre, die durch 4 ohne Rest teilbar sind, sind Schaltjahre.
    * Alle Jahre, die durch 100 ohne Rest teilbar sind, sind keine Schaltjahre.
    * Alle Jahre, die durch 400 ohne Rest teilbar sind, sind wiederum Schaltjahre.

[koehlerbv]

Axel - lies Dir bitte die von Ulrich dokumentierten Fehlerfälle durch. Du wirst sehen - so einfach ist es nicht.

A-Bär (und ich habe mein Posting dahingehend geändert - DANKE für den Hinweis, Axel): Ich meinte natürlich nicht "LS", sondern die API.

Bernhard

[flaite]

Hab ich durchgelesen.
Regel 2 passt auf 1700, 1500, 1400, 1300, 1100 und 1000
1200 und 1600 scheinen zu funktionieren wie nach dem Gregorianischen Kalender in der frühen Neuzeit spezifiziert. Das ist Regel 3. Regel 3 hebt Regel 2 auf.
Vielleicht haben die für die Zeit nach der Boston Tea Party ein paar Spezialregeln eingeführt.

[koehlerbv]

Axel, 1000 passt auch (obwohl vor 1782 oder 1776 als "Gründung U.S.A. - alles vorher ist mir wurscht!"). 1800 und 1900 passen auch - also sind es wirklich die Jahre, die Ulrich genannt hat, in denen Notes an der intern nachweislich bekannten Regel scheitert.

Egal: NotesDateTime braucht (fast) keine Sau, wir müssten jetzt nur noch eine funktionierende Variante für die Formelsprache finden. Dazu habe ich aber heute Nacht keine Zeit, und andere dürfen auch mal ran 

Bernhard