Thema: Covella - Fantasy-Kalender - DSL für beliebige Systeme von Zeitmessung

[Talwyn]

So,

habe mich ein wenig mit dem Code und den Konzepten auseinander gesetzt und kann jetzt endlich meinen unqualifizierten Senf dazu geben. Vorsicht, ab hier wird es für Nicht-Entwickler wahrscheinlich etwas kryptisch.

Grundsätzlich denke ich, wir sollten uns Modell vom Prozess der Konstruktion trennen: Wir brauchen ein möglichst einfaches, möglichst intuitives API, mit dem man einen Kalender definieren kann. Mir hat der erste Wurf von 1of3 sehr gut gefallen, und aus meiner Sicht wäre es wünschenswert, wenn das Skript für die Definition eines Kalenders so simpel bleiben könnte. Die gute Nachricht ist: Ich bin mir ziemlich sicher, das das auch klappt, aber dazu später mehr. Unabhängig von dieser Builder-API brauchen wir eine Datenstruktur, die die Domäne möglichst treffend abbildet. Wir haben also so gesehen zwei (oder mehr - auch dazu später mehr) "Pakete": Das Builder API und das Domänenmodell. Das Builder API definiert Funktionen, die - so sie aufgerufen werden - Objekte aus dem Domänenmodell erzeugen.

Für das Builder API bauen wir eine möglichst gut lesbare DSL (wie ja schon geschehen / bzw. begonnen)
Für das Domänenmodell modellieren wir so schnörkellos wie möglich unsere Anwendungsdomäne. Wir brauchen also geeignete Klassen, die die einzelnen Informationen, welche einen Kalender beschreiben, sowie die Beziehungen zwischen diesen Informationen möglichst einfach abbilden.

Wir sollten allerdings denke ich vermeiden, die Logik zur Konstruktion unserer Modellobjekte mit eben diesen Objekten zu vermischen: Die Definition eines Kalenders ist ein halbwegs komplexer Prozess, es lohnt sich diesen von der Repräsentation der Daten zu trennen, die von ihm (dem Prozess) erzeugt wird. Dazu verwendet man in der Regel das Builder Pattern. Selbiges ist ziemlich formalistisch definiert, weil es in der GoF-Bibel steht, aber so genau muss man das nicht nehmen. Wichtig ist die Essenz: Trenne einen komplexen Erzeugungs-Prozess vom (am Ende dieses Prozesses stehenden) Produkt. Ein Auto weiß nichts über den komplizierten Prozess, der durchlaufen werden musste, um es herzustellen, ebenso verhält es sich mit unserem Kalender.

Was das Builder API angeht, gefällt mir wie gesagt der ursprüngliche Vorschlag nach wie vor sehr gut, und ich denke auch, dass wir uns davon nicht weit entfernen müssen. Tage sind zwar sicherlich eine zu grobe Zeiteinheit für ein flexibles Kalendersystem, jedoch denke ich, dass in >95% aller klassichen RPG-Settings zumindest mal gilt, dass eine Stunde 60 Minuten und eine Minute 60 Sekunden hat. Selbst der 24-Stunden-Tag ist sehr weit verbreitet. Ich meine, dass diese Werte sich daher als sensible defaults anbieten - sie sind genau das, was in 95% zutrifft, von daher sollte es so einfach wie möglich sein, einen Kalender mit diesen Standardwerten zu erzeugen. Natürlich gibt es die Ausnahmen, und die sind auch nicht so extrem, dass man sie ignorieren könnte: Die Rotationsgeschwindigkeit von Planeten wird in Scifi-Settings häufig explizit definiert. Das Builder API sollte es also möglich machen, Tage mit 20 oder 32 Stunden zu definieren - oder Hell-Dunkel-Zyklen, die Soliden heißen und jeweils 4 Quartäre haben, welche unterteilt werden in jeweils 10000 Decamils. Dies sollte nach Möglichkeit ebenfalls mit dem Builder API relativ einfach zu beschreiben sein, da es sich bei solchen Konstrukten aber sicherlich um Exoten handelt, ist es aus meiner Sicht ok, wenn diese Spezialfälle eine etwas umständlichere Beschreibung durch die DSL erfordern. Für den Standardfall sollte es aber z.B. nicht nötig sein explizit zu definieren, dass ein Tag 24 Stunden zu 60 Minuten zu 60 Sekunden hat. Analog dazu plädiere ich für Convenience-Funktionen überall dort, wo es einen Fall gibt, den man in der überwältigenden Mehrheit der Fälle als Standard annehmen kann. Beispiel Events: Meist dürfte es sich hier um einen Tag - z.B. einen Feiertag handeln, insofern wäre es ein sensible default, von einer Dauer von einem Tag auszugehen. Ich denke auch, dass man standardmäßig annehmen kann, dass ein solcher Event sowohl vorwärts als auch rückwärts wiederholt werden sollte. Auch hier gibt es bestimmt genügend gute Beispiele für Ausnahmen, aber ich denke, unter dem Strich ist das API mit solchen Annahmen meistens einfacher zu verwenden.

[Talwyn]

@Antariuk: Covella soll erstmal wirklich nur eine Bibliothek werden, d.h. es handelt sich dabei nicht um eine Anwendung, die Endanwender auf ihrem Device ausführen können, um damit irgendwas zu tun. Stattdesen können andere Anwendungen Covella benutzen, um Funktionen rund um einen fiktional Kalender bereitzustellen. Das könnte dann zum Beispiel eine Kampagnen-Tagebuch-App sein, die ein Interface ähnlich z.B. Google Calendar hat, dabei aber auf einem FR- oder Golarion-Kalender läuft. Eine solche App könnte dann auch eine Funktion beinhalten, um die Kalenderdaten z.B. als PDF zu exportieren.

[Anastylos]

Es gibt bereits einen ziemlich guten Kalender http://donjon.bin.sh/fantasy/calendar/
Wobei es auf der Seite auch noch andere coole Sachen gibt. Wenn ihr ein eigenes Tool baut wünsche ich mir eine Option für zufällige Feiertage mit Namen.

[Pyromancer]

Das ist dem Programm im Grunde Wumpe. Du kannst damit auch synodischen, siderischen und tropischen Monat für fünf Monde tracken, wenn das dein Ding ist. Oder das Erscheinen der Feenkönigen bei Hofe nebst dem Flackern des Artefakts von Schnackpuck und die Aussaatzeit von Yamok-Wurzeln. Muss ich nicht wissen, deshalb hab ich ja versucht eine recht eingängige Spezialsprache zu schreiben, damit man ohne viel Aufmachung ein System zur Zeitmessung schreiben kann.

Wie sieht es aus mit den Auf- und Untergangszeiten von Himmelskörpern?

[1of3]

Nicht direkt. Also nicht in diesem Stadium. Also höchstens insofern, dass du die Dauer der Helligkeitsperiode für einen Breitengrad übers Jahr eingibst und ausrechnest.

Tage sind zwar sicherlich eine zu grobe Zeiteinheit für ein flexibles Kalendersystem, jedoch denke ich, dass in >95% aller klassichen RPG-Settings zumindest mal gilt, dass eine Stunde 60 Minuten und eine Minute 60 Sekunden hat. Selbst der 24-Stunden-Tag ist sehr weit verbreitet. Ich meine, dass diese Werte sich daher als sensible defaults anbieten - sie sind genau das, was in 95% zutrifft, von daher sollte es so einfach wie möglich sein, einen Kalender mit diesen Standardwerten zu erzeugen.

Gut. Dann könen wir also leicht eine Schwelle über und eine unter dem Tag annehmen. Wenn user uns nichts erzählst, nehmen wir an, dass Tage wie gewohnt funktionieren. Das vereinfacht ein paar Dinge.

Events: Meist dürfte es sich hier um einen Tag - z.B. einen Feiertag handeln, insofern wäre es ein sensible default, von einer Dauer von einem Tag auszugehen. Ich denke auch, dass man standardmäßig annehmen kann, dass ein solcher Event sowohl vorwärts als auch rückwärts wiederholt werden sollte.

Events standardmäßig mit Tageslänge ist OK für mich. Ich hab so Stiftungstage von irgendwelchen Tempeln im Kopf, die eben erst ab einem Zeitpunkt gestiftet sind. Aber klar. Standard muss sein, dass der Event sich in Zukunft und Vergangenheit ausstreckt. Wichtig wär mir halt z.B. Ostern berechnen zu können.

[Talwyn]

Ja wie gesagt, es sollte möglich sein. Man sollte es dem Anwender nur ersparen müssen, für alle 36 Feiertage seines Kalenders explizit angeben zu müssen, dass sie nur einen Tag lang dauern und in beide Richtungen wiederholt werden sollen.

Ich frage mich gerade überhaupt ob sowas wie Ostern tatsächlich auf Kalender-API-Level verankert werden sollte. Im Grunde ist das ja ein Ereignis, das nur für einen bestimmten Kulturkreis gilt. Ich würde das deswegen wohl eher als Datensatz betrachten, den man in einer Applikation speichert, die Covella verwendet, also so als würde ich in meinen Outlook-Kalender einen neuen Termin eintragen. Die Faerûnischen Feiertage wären hingegen ein anderes Biest, weil diese ja nicht an einem regulären Kalendertag auftreten - stattdessen handelt es sich bei ihnen ja effektiv um "Monate mit nur einem Tag".

@Anastylos: Im Moment bauen wir noch kein Tool für den Endanwender, sondern versuchen erstmal nur das Konstrukt "beliebiger fiktionaler Kalender" in Gestalt von Programmcode so zu formalisieren, dass man am Ende eine Bibliothek erhält, die es einfach macht, allerlei Anwendungen zu entwickeln, deren Funktionen sich um einen solchen fiktionalen Kalender drehen. Bei einer solchen Anwendung kann es sich dann z.B. um eine Art "Outlook-Kalender für Golarion" handeln, eine App, die den Fortschritt der Ingame-Zeit korrekt trackt, oder was auch immer. So weit sind wir aber momentan noch nicht, da der Anspruch eine generisch verwendbare Bibliothek zu entwickeln die Sache recht kompliziert macht.

[1of3]

Ich frage mich gerade überhaupt ob sowas wie Ostern tatsächlich auf Kalender-API-Level verankert werden sollte. Im Grunde ist das ja ein Ereignis, das nur für einen bestimmten Kulturkreis gilt.

Ne, es geht mir nicht um Ostern an sich. Es geht mir um Aufgaben vom Typ: "Finde den ersten Sonntag nach dem ersten Vollmond im Frühling." Das ist Ostern. Oder eben: "Finde Freitag den 13." Mithin also Ereignisse, die über das Zusammenwirken verschiedener Zyklen definiert sind. Ostern ist so das komplexeste und bekannteste Beispiel in unserem Kulturkreis.

Du hast natürlich recht, dass die Feiertage im Harptos-Kalender - man nennt sowas auch "leere Tage" - ein anderes Ding sind.

[Talwyn]

Ja schon klar, aber nehmen wir dochmal Real-World-Kalender-Apps oder auch bestehende Datums-APIs wie etwa java.util.Calendar oder Joda-Time - die wissen in der Regel selbst nicht, wann Ostern ist. Wenn sie mir allerdings sagen, wann der Frühling beginnt und wie die Mondphasen verlaufen, dann kann ich als Anwender ausrechnen, wann Ostern ist. Ich finde daher, dass diese "Intelligenz" nicht innerhalb von Covella verortet werden sollte. Zur Illustration habe ich mal ein Diagramm angehängt.

Ich bin ein Fan von kleinen Software-Komponenten, die nur eine Sache tun, diese aber dafür gut. Und das "gut" ist leichter zu erreichen, wenn man die Komplexität gering hält. Im Prinzip ist das übrigens genau die Design-Philosophie, die hint den UNIX Pipes steckt, und dort, sowie in vielen davon inspirierten Architekturen hat sich das bewährt.

[gelöscht durch Administrator]

[1of3]

Wahrscheinlich meinen wir das gleiche. Um sicher zu gehen: Welche Funktionalität sollte das Interface enthalten, das die Covella-Bibliothek der Anwendung bereitstellt?

[Talwyn]

Ok, jetzt nähern wir uns dem Kern der Sache. Komme nur jetzt nicht dazu, das zu beschreiben. Ich sehe zu, dass ich es heute Abend schaffe, mir was aus den Fingern zu saugen.

[Talwyn]

Anforderungen an die Covella-Kalender-Bibliothek

Als Entwickler einer App, die dem Informationsmanagement beim Leiten und Vorbereiten von Pen & Paper Rollenspielen (insbesondere mit Schwerpunkt auf Hexploration und einer offenen Sandbox), benötige ich eine Bibliothek, die geeignete Klassen und Funktionen für die Darstellung eines fiktionalen Kalenders zur Verfügung stellt. Folgende Anforderungen müssen dabei grundsätzlich erfüllt sein:

COVELLA-1
Die Bibliothek darf nicht an ein bestimmtes Kalendersystem gebunden sein. Stattdessen muss sie in der Lage sein, beliebige fiktionale Kalender abzubilden. Beispiele wären z.B. die Kalender aus bekannten Kampagnensettings wie Aventurien, den Vergessenen Reichen, Greyhawk, Dark Sun, Golarion, Glorantha oder Barsaive.

COVELLA-2
Die Definition eines Kalendersystems sollte so einfach wie möglich sein, so dass auch Anwender ohne Programmierkenntnisse in der Lage sind mit Hilfe einer kurzen Anleitung, den Kalender ihrer bevorzugten Kampagnenwelt abzubilden. Hierfür bietet sich eine domänenspezifische Sprache (domain-specific language) an, die sich nach Möglichkeit an der natürlichen Sprache orientieren sollte. Diese DSL sollte zunächst die gängigsten Fälle abdecken und soweit möglich mit sensible defaults arbeiten, um unnötige Schreibarbeit zu vermeiden (z.B. sollte davon ausgegangen werden, das ein Tag - sofern explizit nicht anders spezifiziert - 24 Stunden zu je 60 Minuten zu je 60 Sekunden hat).

COVELLA-3
Wurde ein Kalendersystem definiert, so ist es möglich hierzu eine Kalender-Instanz zu erzeugen, indem man einen Startzeitpunkt definiert. In Pseudocode ausgedrückt könnte das in etwa so aussehen:

Code: [Auswählen]

myCalendar = new Calendar based on system "Calendar of Harptos" with start date "13th Marpenoth 1485 DR"

COVELLA-4
Das Kalenderobjekt stellt eine Funktion bereit, die es ermöglicht, den gegenwärtigen Zeitwert zu verändern, indem man eine Größe addiert oder subtrahiert. Beispiele:

Code: [Auswählen]

advance myCalendar by 3 days
advance myCalendar by 4 hours and 30 minutes
rewind myCalendar by 1 year

COVELLA-5
Die Bibliothek sollte zumindest die Formatierung eines Datums als Zeichenkette unterstützen, nach Möglichkeit auch das Erzeugen eines Kalenderobjekts aus einer Zeichenkette, die ein bestimmtes Format hat. Beispiele:

Code: [Auswählen]

myCalendar = {
    system: 'Calendar of Harptos' ,
    interntalValue: 189798297898L
}

textualRepresentation = myCalendar.format() // assuming standard format
assert that textualRepresentation equals "13th Marpenoth 1485 DR"

COVELLA-6
Das Kalenderobjekt stellt Funktionen zur Verfügung, um auf die einzelnen Komponenten des in ihm gespeicherten Zeit-Werts zugreifen zu können:

Code: [Auswählen]

assert that myCalendar.getYear equals 1485
assert that myCalendar.getDayOfMonth equals 13 // start counting at 1, nobody wants to count days of month starting at 0
assert that myCalendar.getMonth equals 10 // start counting at 1, nobody wants to count month number starting at 0
assert that myCalendar.getMonthName equals "Marpenoth"
assert that myCalendar.getMonthAlias("poetic1") equals "Leafall"
assert that myCalendar.getYearName equals "Year of the Iron Dwarf's Vengeance"

Das mal als erster Wurf. Muss man sicher noch verfeinern, aber das funktioniert erfahrungsgemäß besser, wenn man sich gegenseitig den Ball zuspielen kann.

[1of3]

myCalendar = {
    system: 'Calendar of Harptos' ,
    interntalValue: 189798297898L
}

OK. Nach meinem Begriff ist das kein Kalender, sondern ein Datum. Der Kalender ist das System. Aber das ist Terminologie.

Ein Datum ist also eine Klasse mit einem Zeitstempel, den man an Hand eines assoziierten Kalendersystems manipulieren kann:
- Man kann den Zeitstempel in Text umwandeln.
- Man kann aus einem passenden String einen Zeitstempel parsen.
- Man kann einen neuen Zeitstempel finden, der auf Beschreibungen wie "drei Monate später" passt.

In letzterem Fall sollten wir aufpassen: Es gibt einen Unterschied zwischen drei Monate später und drei Stunden später. Letzteres manpuliert den Zeitstempel in vorhersagbarer Weise, der Monat kann dagegen ulkige Sachen machen, also mal 30, mal 31 und mal 28 Tage später. Wir sollten hier darauf achten, zwei unterschiedliche Methoden anzubieten und die eine darf für Monat, Jahr oder sonstige verschieden lange Zeiteinheiten nicht funktionieren.

Parsen aus einem String ist grundsätzlich kein Problem. Schön wäre es natürlich, wenn man aus der Definition der formatierten Ausgabe auch gleich die passenden Informationen zum Parsing generiert. Aber ich hab ne Idee, wie das gehen könnte.

Ich würde noch ein Kriterium hinzufügen:

Covella-7
Es sollte möglich sein zu Teilintervallen zu navigieren. Also etwa zum dritten Montag im elften Monat.

Code: [Auswählen]

year therein month 11 therein third monday
Dann wird das Parsing auch direkt einfacher.


Aber ansonsten gehen wir völlig d'accord.

[Talwyn]

Ja du hast Recht, das was ich hier als Kalender bezeichne ist ein Datum. Richtiger wäre:

Code: [Auswählen]

calendar = new Calendar("Calendar of Harptos")
myDate = calendar.getDate("13th Marpenoth 1485 DR")
// oder
myDate = calendar.getDate(1485, 10, 13)


[1of3]

OK. Eine Frage bleibt dann noch:

Code: [Auswählen]

myDate.[b]getYear[/b] equals 1485
Wenn man jetzt ein Datum nach so einer Information, wie seinem Jahr fragt, was für ein Objekt erhält man dann?

Ich schlage vor:

- Das returnierte Objekt ist ein Interval.
- Intervalle haben je einen Zeitstempel, wo sie anfangen, und einen, wo sie aufhören.
- Intervalle können wohlbezeichnete Teilintervalle liefern.

Wenn man speziell nach einem Monat oder einem Jahr fragt, haben wir noch ein bisschen mehr, denn dieses Intervall entspricht auch einer bekannten Zeiteinheit. Diese Art von Interval...
- hat einen Bezeichner, also z.B. Woche, Monat.
- kann herausfinden, wievielte so bezeichnete Zeitintervall es in einem anderen wohlbezeichneten Zeitintervall ist, also z.B.

Code: [Auswählen]

november indexIn year // returns 10, weil Zählung fängt bei 0 an
- falls diese Art von Intervallen Namen hat, kann man sie natürlich nach ihrem Namen fragen

Code: [Auswählen]

myDate.getMonthName
Ist dann also identisch zu:

Code: [Auswählen]

myDate.getMonth.name ...

[Talwyn]

Das Intervall ist sicher auch oft ein hilfreiches Konstrukt, ich würde das nur nicht mit dem Datum vermischen. Wenn ich ein Datum nach seinem Jahr frage, dann meine ich die Jahreszahl, denn das Datum selbst repräsentiert ja einen ganz bestimmten Punkt innerhalb des Intervalls, welches das Jahr natürlich in einem anderen Kontext.

Ein Zeitintervall wäre aus meiner Sicht hingegen eine eigene Klasse, die andere Funktionen bereitstellt. Convenience-Methoden zur Erzeugung eines Zeitintervalls auf Basis einer Jahreszahl sind aber natürlich nützlich:

Code: [Auswählen]

interval yearOfTheIronDwarfsVengeance = calendar getInterval for year 1485 // ==> [1485-01-01T00:00:00, 1486-01-01T00:00:00[
// oder aber:
interval yearOfTheIronDwarfsVengeance = myDate getInterval for unit year // ==> Same as above

Ich denke bei sowas immer auch an die Verwendung eines APIs im Sinne einer Schnittstelle. Selbige sollte einfach und intuitiv zu verwenden sein und auf den üblichen Use Case hin ausgelegt. Die interne Repräsentation der Daten darf ja gerne eine präzise Modellierung der Anwendungsdomäne sein, aber die Schnittstelle sollte einfach den Bedarf des Benutzers abdecken.

[Talwyn]

Und was die Namen angeht, wie wäre es mit sowas:

date.get(MONTH) ==> 10
date.getName(MONTH) ==> "Marpenoth"
date.get(YEAR) ==> 1485
date.getName(YEAR) ==> "Year of the Iron Dwarf's Vengeance"

[1of3]

In Ordnung. Dann haben wir etwa folgende Funktionen auf einem Datum.

def get : Int
def getName : String
def getAlias : String
def getInterval : Interval

Jeweils parametrisiert mit der Einheit.

[Talwyn]

Klingt gut soweit.

[Shihan]

Mal eine Zwischenfrage, weil mich das als Entwickler auch interessiert:
Habe keinerlei Erfahrung mit Scala. Wie einfach lässt sich denn eine damit erstellte Bibliothek in ein bestehendes Java-Projekt einbinden?

[1of3]

Grundsätzlich kein Problem. Sind .jar-Dateien, wenn der Compiler fertig ist.

Von Java auf Scala zugreifen wirkt manchmal etwas hässlich, weil Scala Operatoren als Methodennamen benutzen kann. Also Java kann ja z.B. nicht einfach "+" benutzen, um eine Funktion auf einem Objekt zu aufzurufen, das würde dann zu $plus umgewandelt. Wir können aber problemlos jeweils ein lesbares Alias einfügen, also meinetwegen "add".

Wenns dich interessiert: Basics von Venkat Submaraniam

[Talwyn]

Ich habe vor einen Java Wrapper für die Bibliothek zu bauen sobald sie mal steht. Weil, was 1of3 sagt gibt auch noch ein paar Sprachkonstrukte, die Java nicht so ohne weiteres beherrscht.

Gesendet von meinem Nexus 5 mit Tapatalk

[Skeeve]

Hm, ich hätte das Ganze von der astronomischen Seite aufgezogen. Solare und lunare Zyklen (vielleicht mit mehreren Monden), Jahreszeiten, Feiertage, Sonnwenden und Tagundnachtgleichen, Aussaat und Ernte, wiederkehrende Wetterphänomene, darum geht es doch eigentlich, nicht darum, Tage runterzuzählen.

Ungefähr das (lunare und solare Zyklen) wollte ich ungefähr zur gleichen Zeit auch schreiben. Wobei dies

Was ich mit Herausforderung bei den Kalendern meinte ist: Es sollte für Nicht-Programmierer möglich sein, auf relativ einfache Weise den Kalender ihrer Spielwelt so zu beschreiben, dass die App damit arbeiten kann.

das ganze vermutlich etwas komplizieren könnte...

[Boba Fett]

Wenn ihr beim Programmieren eine Übung braucht, dann realisiert doch mal folgenden Kalender:

Wir nehmen die Erde als Umlaufzeit zum Vorbild, also 365 TAge im Jahr. Jedes 4. Jahr ein Schalttag, ausser in den Hunderten, wobei die "außer" Regel in den Tauserndern doch wieder eine Ausnahme bildet - die Tausender haben ein Schaltjahr.
Soweit so gut, das ist unsere Welt (derzeit).

Das Kalenderjahr beginnt bei der Tag-Nachtgleiche im Frühling der Nordheminsphäre.
Jeder Monat hat exakt 30 Tage.
Jede Woche hat 6 Tage, also hat Jeder Monat 5 Wochen.
(Die 12 x 30 Tage machen also schon mal 360 Tage im Jahr aus. Fehlen noch 5 ...)
Vor jedem Quartal (3 Monate) wird ein außerhalb der Monate und Wochentage liegender Tag an den Tagen der Tag/Nacht-gleiche, zu Midsommer und Midwinter zusätzlich eingeschoben.
Der Jahreswechsel bekommt einen weiteren extra Tag als allerletzter Tag im Jahr.
Der Schalttag wird zwischen dem letzten Tag und dem Quartalsbeginntag eingeschoben.

[1of3]

@Boba: Meinst du so?

Code: [Auswählen]

val month = (Days(6) as "week") *5 as "month"
val quartal= Days(1) as "extra day" + month *3

val standardYear = quartal *4 as "year"
val leapYear = (quartal * 4 + Days(1) as "leap day" ) as "year"

val fourYearCycle = standardYear * 3 + leapYear

val century = fourYearCycle * 24 + standardYear * 4

val millenium = century * 9 + fourYearCycle * 25

val meinKalender = Calendar ( millenium )

[Skeeve]

Ich glaube bei

Code: [Auswählen]

val standardYear = quartal *4 as "year"
val leapYear = (quartal * 4 + Days(1) as "leap day" ) as "year"


fehlt noch der Jahreswechsel. Also vielleicht so:

Code: [Auswählen]

val standardYear = quartal *4 as "year" + Days(1) as "turnOfTheYear"
val leapYear = (quartal * 4 + Days(1) as "leap day" ) as "year" + Days(1) as "turnOfTheYear"

Wobei ich keinen Plan habe ob das die korrekte Syntax ist.  Dazu habe ich viel zu wenig Ahnung von Scala und Java.