Wikipedia Diskussion:Lua/Werkstatt/Datum und Uhrzeit

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 1 Jahr von Vollbracht in Abschnitt Neutrales Datenformat
Zur Navigation springen Zur Suche springen

Eingabe[Quelltext bearbeiten]

Ein neues Zeit-Objekt sollte durch einen Konstruktor im Format Zeit:new(<Eingabestring>) erzeugt werden. Derzeit ist eine Zeitangabe durch Parameter von Seitenautoren dann durch folgenden Code zu normalisieren:

local t = mw.language.getContentLanguage():formatDate("+Y-m-d\\TH:i:s\\Z", timeStr)

Er hat dann genau das Format, in dem Zeitangaben auch in Wikidata abgespeichert werden. Geht es in diesem Artikel darum, diese Funktion durch eine solche zu ersetzen, die aus einem noch unbekannten Zeitformat das Zeit-Objekt direkt erzeugen kann? --Vollbracht (Diskussion) 05:19, 30. Okt. 2022 (CET)Beantworten

Diese Frage ist zu kryptisch um sie beantworten zu können. Objekte können aus beliebig viel unterschiedlich formatierten Ausgangsdaten gebildet werden. --PerfektesChaos 17:19, 30. Okt. 2022 (CET)Beantworten
Vielleicht verstehst Du mich so: Du selbst hast aufgezeigt, wie ein Eingabestring normalisiert werden kann, sodass er anschließend mit einem einfachen match-Aufruf geparst werden kann. Geht es jetzt darum, diesen Zwischenschritt wegzulassen? --Vollbracht (Diskussion) 17:24, 30. Okt. 2022 (CET)Beantworten
Auf welche Weise eine externe Repräsentation formatiert ist, hat absolut rein gar nichts mit dem umseitigen Datenmodell zu tun, in das es dann geparsed wird. Umseitig steht auch nix von irgendeiner bestimmten externen Formatierung.
  • Geparsed werden sollen für dieses Wiki „Alle zweifelsfreien Datumsformate für den deutsch- und englischsprachigen Raum“ und eine breite Vielfalt wurde beispielhaft aufgezählt.
  • Genauso könnten auch französische oder italienische Formatierungen in das Objekt geparsed werden, und das Objekt kann auch in fremdsprachlichen Formatierungen ausgegeben werden. Die externe Formatierung hat nichts mit dem neutralen Datenformat zu tun, in das oder aus dem es abgebildet wird.
--PerfektesChaos 17:08, 31. Okt. 2022 (CET)Beantworten
Du hast die Frage nicht beantwortet. Es war eine geschlossene Frage.
Ja -> Alle möglichen Eingaben für einen Konstruktor, den das Objekt kennen soll, müssen einzeln spezifiziert werden.
Nein -> Es reicht, eine kleine Auswahl von format-strings zu spezifizieren, sodass Zeichenfolgen mit Zeitangaben, die von obiger formatDate-Methode damit formatiert wurden, von einem Konstruktor geparst werden können.
Deine Formulierung „Alle zweifelsfreien Datumsformate für den deutsch- und englischsprachigen Raum“ schließt hingegen auch "782000013 Minuten vor Tagesbeginn der Krönung von King Charles III." mit ein. Eine vernünftige Spezifikation ist etwas, worauf sich Nutzer verlassen können und wollen. Diene Formulierung ist hierfür nicht geeignet. --Vollbracht (Diskussion) 19:30, 31. Okt. 2022 (CET)Beantworten

Neutrales Datenformat[Quelltext bearbeiten]

Die Struktur des Datenformates sollte verändert und mit der des Wikidata-Datenformates kompatibel gemacht werden. Zusätzliche Felder mögen enthalten sein. Die bestehenden Informationsdarstellungen sollten jedoch beibehalten werden. Im Einzelnen:

time[Quelltext bearbeiten]

Das Feld "time" in der Wikidata datavalue.value Zeitangabenstruktur enthält die Informationen Jahr, Monat, Tag, Stunde, Minute, Sekunde und Ära (hier durch ein Vorzeichen dargestellt). Ich schlage vor, in der Datenstruktur entsprechend hierfür die Felder year, month, day, hour, min, sec und era zu verwenden, wie im Modul:Wikidata/Time realisiert. era ist dann kein Wahrheitswert, sondern ein Zeichen ('+', oder '-'). Das vereinfacht die Verarbeitung von Wikidata-Informationen. --Vollbracht (Diskussion) 06:01, 30. Okt. 2022 (CET)Beantworten

Die umseitig aufgelisteten Komponenten sind englischsprachig und nicht „Jahr, Monat, Tag, Stunde, Minute, Sekunde und Ära“ und es gibt auch noch zone, leap, jul.
era ist dann kein Wahrheitswert, sondern ein Zeichen ('+', oder '-'). Das vereinfacht die Verarbeitung von Wikidata-Informationen.“
Abgelehnt.
In einem guten Datenmodell erfordert eine Attribuierung nicht mehr Variationsmöglichkeiten als von der Sache her erforderlich.
Weil es hier um eine Ja-Nein-Entscheidung geht, ist ein boolescher Wert völlig hinreichend um vor/nach auszudrücken; und damit auch die optimale und nicht weiter zu verbessernde Realisierung.
Die vorgeschlagene Zeichenkette hat unendlich viele Möglichkeiten, sie zu interpretieren, es könnte auch "J" oder "G" oder "g" oder "v" oder "b" in einer konkreten Anwendung aufschlagen. Dann muss für alle unerwünschten und unverständlichen Werte eine Fehlerbehandlung, verständliche Erläuterung, Wartungskategorie programmiert werden. Bei einem booleschen Wert entfällt das.
Die Programmierung ist damit auch denkbar simpel:
if t.era then
    -- v.u.Z.
else
    -- n.u.Z.
end
Dein Vorschlag erfordert überall
if t.era == "-" then
    -- v.u.Z.
elseif t.era == "+" then
    -- n.u.Z.
else
    -- Fehlermeldung, Wartungskategorie
end
Soll hingegen ein boolescher Wert als Zeichenkette hinterlegt werden wie das etwa im Wikitext unabdingbar ist, dann ist die Unterscheidung wieder sehr einfach:
  • "era=1" bedeutet: true
  • Alles andere bedeutet erstmal: false
--PerfektesChaos 17:19, 30. Okt. 2022 (CET)Beantworten
Ich habe das mal eben überprüft: Wikidata fängt das Jahr 0 nicht ab und zeigt es als 0 CE an. Vor diesem Hintergrund sollten auch wir nicht mit einer kontinuierlichen Jahreszählung arbeiten (und 0 mit 1 v.Chr. übersetzen), sondern mit den altbekannten diskontinuierlichen Jahreszahlen (-1 = 1 v.Chr.). Wir sollten das ebenso halten und entsprechend spezifizieren.
Mein Vorschlag bietet derweil weiterhin:
if not t.era then
	-- arbeite mit nicht spezifizierter Ära
elseif t.era == '+' then
	-- n.Chr.
else
	-- v.Chr.
end
Erfahrungsgemäß ist eine solche Darstellung besser verständlich und wartbar. @PerfektesChaos: Du selbst hast auch darauf hingewiesen, dass ja auch die Jahreszahl kein Pflichtfeld ist und ein Fehlen dieses Feldes bewusst behandelt werden muss. Gleiches sollte entsprechend auch für die Ära gelten. --Vollbracht (Diskussion) 01:05, 31. Okt. 2022 (CET)Beantworten
Ich darf noch mal darauf hinweisen, dass die ISO sich ohnehin nur auf das nichtproleptische gregorianische Kalendermodell bezieht und für alle Abweichungen dazu Vereinbarungen zwischen Sender und Empfänger fordert.
Ich tendiere übrigens nicht dazu, weiteren Werten für era eine konkrete Bedeutung beizumessen. era='n' für ausdrücklich nicht spezifizierte Ära-, oder Jahreswerte, oder era='w' für Zykluslängen von Wiederholungen scheinen mir aber denkbar. Ich stelle das daher gerne zur Diskussion. --Vollbracht (Diskussion) 01:36, 31. Okt. 2022 (CET)Beantworten
Es gibt nur die Frage vor oder nach „Christus“ und keine dritte; damit auch keine Notwendigkeit über die schon drei Werte true, false, nil hinaus zusammenphantasierte weitere Messias-Geburten zu unterstützen.
Das Datenmodell hat die Aufgabe, die rund 50 Millionen Datumsangaben auf unseren Seiten zu unterstützen, und die sind mit minimalen Sonderfällen im von Julius Cäsar eingeführten Kalendermodell angegeben. Insbesondere geht es um das Datum, an dem ein Buch gedruckt wurde, ein Schiff vom Stapel lief, eine Webseite abgerufen wurde, oder eine Löschdiskussion eröffnet wurde. Nichts davon steht in irgendeinem anderen Kalendersystem.
Die „anderen Kalender“ sind vorwiegend Mondkalender, das heißt: Das Jahr hat dann keine 365/366 Tage, es hat ggf. keine 12 Monate. Auf jeden Fall hat der „3. Monat“ keine 31 Tage. Ggf. gibt es zusätzlich zu den 12 Monaten noch weitere Extra-Tage im Jahr. Der Tag hat keine 24 Stunden, beginnt auch nicht mitten in der Nacht sondern ggf. bei Sonnenuntergang und die Konzepte der Minuten und Sekunden sind völlig unbekannt. Weiterhin gibt es auch keine era , weil Gott die Welt am 1. Tag des Jahres 1 erschaffen hat.
Deshalb ist das umseitig definierte Objekt grundsätzlich ungeeignet, um andere als die klassischen Sonnenjahre seit 40 v. Chr. abzubilden. Die implizierte Einteilung passt nur auf den Sonnenkalender in der seit Julius Cäsar in Europa gebräuchlichen Methodik, und ist auch für nichts anderes bestimmt.
  • Auch das Julianische Datum wäre nicht damit abbildbar, weil es dort weder Jahre noch Monate gibt, dafür die Nummer des Tages im Monat (den es nicht gibt) meist deutlich über 31 liegt.
Andere Kalendersysteme kannst du ja gern aufmachen, aber sie bräuchten jedes ihr eigenes, individuelles Datenmodell und haben mit dem umseitigen Objekt nichts zu tun. Deshalb bedarf das umseitig dargestellte Objekt auch keines Schalters für Nicht-Sonnenkalender. Das hat auch nichts mit vermeintlichen „Schwächen“ zu tun, sondern eine Struktur der realen Welt lässt sich nur in deren spezifischer Objekt-Struktur repräsentieren, und ein fundamental anders organisiertes Gebilde in der realen Welt lässt sich nicht auf eine dazu inkompatible und völlig fremde Struktur abbilden.
  • Andere Systeme heißen „andere Systeme“, weil sie halt andere Systeme sind. Julianischer und Gregorianischer Kalender sind hingegen das gleiche System, nur halt mit einem kleinen Sprung irgendwo im 16.–18. Jahrhundert, orthodox bis heute.
Deine Haltung, du würdest mit unausgegorenen und nicht zu Ende gedachten spontanen Geistesblitzen irgendwo aufschlagen und die Wiki-Welt würde jetzt nach deinen privaten Wünschen umgebaut, kostet nur extrem viel Zeit und Nerven. Ich kann deine Hirngespinste auch nicht mehr ernst nehmen. Du konsumierst für deine sinnlosen Phantasien Ressourcen, die an anderer Stelle dringend gebraucht würden, und verzögerst dadurch andere und wesentlich wichtigere und dringlichere Sanierungsmaßnahmen.
Umseitiges Datenmodell bildet nicht nur die ISO 8601 ab, sondern ist seit Januar 2014 auch in fast einer Million Seiten dieses Wiki erfolgreich wirksam. Das, wofür es gedacht ist, erfüllt es wirkungsvoll; deine Objekte für den Hebräischen, Islamischen, Chinesischen, Koptischen, Äthiopischen, Bahai-, Maya- oder den Französischen Revolutionskalender kannst du dir gern privat bauen und der staunenden Welt vorstellen. Für die praktische Anwendung in diesem Wiki, auf die das umseitige Datenmodell abzielt, reicht umseitiges erwiesenermaßen vollumfänglich aus.
--PerfektesChaos 17:02, 31. Okt. 2022 (CET)Beantworten
Danke für Deinen Roman. Aber ohne Angabe einer Jahreszahl ist bereits Dein erster Satz für den Eimer. --Vollbracht (Diskussion) 19:31, 31. Okt. 2022 (CET)Beantworten

Kalendermodell[Quelltext bearbeiten]

In Wikidata wird das Kalendermodell mit einer URI angegeben. Hier soll es aber nur durch einen Wahrheitswert definiert sein. Ich schlage vor, das gleich zu halten.--Vollbracht (Diskussion) 04:59, 30. Okt. 2022 (CET)Beantworten

Abgelehnt.
Wie eins drüber: Um eine Ja-Nein-Entscheidung „Julianischer Kalender“ abzubilden, ist ein boolescher Wert im Objekt optimal und nicht mehr verbesserungsfähig; dein Vorschlag hingegen Quelle unendlicher Fehlermöglichkeiten und sinnfreie Verkomplizierung.
--PerfektesChaos 17:19, 30. Okt. 2022 (CET)Beantworten
Du weißt aber schon, dass Du für diesen Ton mehrfach kritisiert worden bist? Und noch mal: Es ist nicht nur der Ton, sondern die Haltung!
Und nun zum Inhalt: Offensichtlich können in Wikidata prinzipiell mehr als diese zwei Kalendermodelle abgebildet werden. Was hindert uns daran, ein Objekt zu schreiben, das auch den 9. Ada 5432 speichern kann? Ein Wahrheitswert kann das nicht leisten.
Deine Meinung hierzu kennen wir bereits. Du hast ja die Spezifikation vorgeschlagen. Was meinen denn die Anderen? --Vollbracht (Diskussion) 17:32, 30. Okt. 2022 (CET)Beantworten
Es interessiert „uns“ einen Scheiß, wie Wikidata deren Aufgaben löst; wir lösen unsere Aufgaben so, wie das in Europa seit Julius Cäsar üblich ist, und „Andere“ gibt es nicht und interessiert sie auch nicht weiter. Zu den sonstigen Kalendermodellen eins drüber. --PerfektesChaos 17:23, 31. Okt. 2022 (CET)Beantworten
Danke!
Thema abgeschlossen! --Vollbracht (Diskussion) 19:33, 31. Okt. 2022 (CET)Beantworten

msec[Quelltext bearbeiten]

(Verschoben aus Projektseite:)

  1. Die Millisekunden tauchen nur zusammen mit Sekunden auf. Ich halte es für unnötig, sie in einem separaten Parameter / Table-Element zu führen. Da Lua sowieso keinen Unterschied zw. Integer und Gleitkomma macht, können die Millisekunden einfach als Dezimalstellen der Sekunden geführt werden.
  2. Benötigte Features
    1. Das julianische Datum - nicht zu verwechseln mit Julianischer Kalender - gehört hier auch hinein. Ebenso auch das modifizierte julianische Datum.
    2. Subtraktion von zwei Zeitpunkten (Zeitspanne berechnen), Addition und Subtraktion einer Zeitdifferenz zu bzw. von einem Zeitpunkt. Das (modifizierte) julianische Datum eignet sich sehr gut dafür.
  3. Bitte keine kryptischen Funktionsnamen. "story", "spec" u.Ä. ist ohne Aussagekraft und es ist auch nicht verboten, deutsche Namen zu nehmen. Letzteres ist für externe Funktionen sogar vorzuziehen.
  4. Das "Programmier-Steno" der Abschnitte 1 bis 4 sollte decodiert werden.
ÅñŧóñŜûŝî (Ð) 23:53, 25. Jun. 2013 (CEST)Beantworten
  • @Millisekunden:
    • Es ist sehr viel einfacher, die Existenz eines separaten Feldes abzufragen, als durch Rumrechnerei mit floor und round und minus hinterher herauszufinden, ob es Nachkommastellen gibt, und welches Ausgabeformat in dieser Situation angemessen wäre. Aus dem Zusammenrühren in einer Gleitkommazahl lässt sich hinterher nicht mehr ermitteln, ob es mit .000 angegeben war. Der Unterschied zwischen 0 und nil ist hingegen leicht festzustellen.
    • Eine Aufgabenstellung kann schließlich lauten: Stelle das Ergebnis einer Berechnung im gleichen Format dar, das für den ersten Operanden benutzt wurde.
  • Das Julianische Datum ist eine reine Tageszählung und passt hier nur bedingt in das jahrweise gezählte Datum; aber eine Konvertierungsfunktion in ein Datum nach Jahren usw. ist machbar.
  • Ich schreibe für die weltweite WikiCommunity und nicht für die deWP.
    • Vorlagenprogrammierer bekommen mindestens den Namen des ersten Parameters nie zu sehen, da er unbenannt ist, und der einzige zweite voraussichtlich auch.
VG --PerfektesChaos 11:48, 13. Jul. 2013 (CEST)Beantworten
Da du sowieso alles bestimmen willst, ist es wohl besser, du machst auch alles allein. Ein Komandostil, wie er hier zutage tritt, wird Ünterstützer weitgehend fern halten. Fragt sich nur, wann du mit der ganzen Arbeit fertig bist. Schade, dass du nicht ausreichend kooperationsfähig bist, um auf eine Weise ein Team zu bilden, bei dem die übrigen Teilnehmer ihr Gesicht wahren können. Dieses Modul musst du - genauso wie die meisten anderen - wohl alleine erstellen. ÅñŧóñŜûŝî (Ð) 22:05, 15. Aug. 2013 (CEST)Beantworten
@ ÅñŧóñŜûŝî. Lang, lang ist's her! Aber seit 11 Jahren und 142 Tagen ist Deine Bemerkung immer noch zutreffend! --Klaus-Peter 12:48, 24. Okt. 2019 (CEST)Beantworten

Können wir nicht auf Millisekunden verzichten? Wo werden die gebraucht? Entscheidend: in Wikidata gibt es die nicht. Dort werden Zeitangaben im Format +yyyy-mm-ddTHH:MM:SSZ abgespeichert. (z.B. +1987-06-05T04:03:02Z, oder -2333-04-05T06:07:08Z) --Vollbracht (Diskussion) 04:53, 30. Okt. 2022 (CET)Beantworten

Abgelehnt.
Das Format gibt mindestens alle nach ISO 8601 adressierbaren zeitlichen Einheiten wieder, völlig egal ob das jetzt im Moment jemand benötigt oder nicht.
Dabei ist es uns auch völlig egal, ob Wikidata irgendwas nicht kann; das ist hier völlig irrelevant.
Umseitig/ISO ist älter und umfassender als Wikidata.
Wikidata ist nur eine einzelne spezielle Anwendung unter bestimmten Einschränkungen, und beherrscht nur eine sehr kleine Teilmenge der ISO 8601.
Beachte übrigens, dass es überhaupt nicht erforderlich ist, dass ein bestimmter Kalendertag angegeben wird; es kann genauso an einem beliebigen Tag eine Dauer 0  Stunden, 0 Minuten und 2  Sekunden repräsentieren und die Laufzeit eines Funksignals von einer irdischen Bodenstation bis zur Rückseite des Mondes beziffern.
Mir ist im übrigen so, als ob zur Sortierung der Dauer bestimmter Ereignisse in Tabellen von den Millisekunden bereits Gebrauch gemacht wurde; etwa weil verschiedene Zeiträume von drei Sekunden in eine bestimmte vorgegebene Reihenfolge gebracht wurden.
--PerfektesChaos 17:19, 30. Okt. 2022 (CET)Beantworten