(Design) Überlagern eines Eingabefeldes

[Horst]

Hi,

derzeit schreibe ich ein ziemlich umfangreiches Webfrontend, was die Berechnung von Kalenderdaten ermöglicht.

Da die einzugebenden Daten leicht zu parsen sind, mache ich die Folgefunktionen vom Format der Eingabe abhängig, was den Vorteil hat, dass das Eingabeformular lediglich _ein_ Input-Field und _einen_ Submit-Button hat.

Folgende Eingaben sind möglich:

• TT.MM.JJJJ (Einzelnes Datum, 1.1.2009, 1.1.-4711)
• Julianischer Tag numerisch (z.B.: 2524602)
• KW.JJJJ (Kalenderwoche, z.B.: 12.2008)
• TT.MM.JJJJ Tage( Datum und Anzahl von Tagen zum Addieren/Subtrahieren)
• TT.MM.JJJJ TT.MM.JJJJ (Zwei Tage zur Berechnung der Differenz zwischen Beiden)
• yJAHR (y2008, y2009, das JAHR wird ausgegeben)
• mMM.JJJJ (m1.1999, m2.2008, der Monat wird ausgegeben)

O.G. Vorteil ergibt sich außerdem auch aus der Tatsache, dass ich die Eingaben ohnehin prüfen muss, daher kam ich auf diese Idee, die ich für gut und benutzerfreundlich befinde.

Was meint denn Ihr dazu?

Viele Grüße vom Baumarkt,
Horst Haselhuhn

[Kalle_B]

Ho,

da Kalenderdaten fast numerisch sind (bis auf den Punkt), lasse ich in meiner Routine nicht-numerische Trennzeichen zu, z.B. das Komma. Dann kann man bequem auf dem Nummernblock tippen.

29          bedeutet: Der 29. dieses Monats, also 29.05.2008
29,06       29.06.2008 (Jahr wird ergänzt)
29,06,2009  (klar)

• TT.MM.JJJJ (Einzelnes Datum, 1.1.2009, 1.1.-4711)
• Julianischer Tag numerisch (z.B.: 2524602)

wer verwendet denn sowas? Da war doch vor 2, 3 Wochen eine Diskussion, dass da ein paar Tage fehlen bei Umstellung vom gregorianischen Kalender. Oder war es andersrum? Jedenfalls ist nicht jedes Datum verfügbar.

• KW.JJJJ (Kalenderwoche, z.B.: 12.2008)
• TT.MM.JJJJ Tage( Datum und Anzahl von Tagen zum Addieren/Subtrahieren)
• TT.MM.JJJJ TT.MM.JJJJ (Zwei Tage zur Berechnung der Differenz zwischen Beiden)
• yJAHR (y2008, y2009, das JAHR wird ausgegeben)
• mMM.JJJJ (m1.1999, m2.2008, der Monat wird ausgegeben)

O.G. Vorteil ergibt sich außerdem auch aus der Tatsache, dass ich die Eingaben ohnehin prüfen muss, daher kam ich auf diese Idee, die ich für gut und benutzerfreundlich befinde.

Ich würde JJJJ nur vorschreiben, wenn vom lfd. Jahr abweichend.

Kalle

[LX]

Was ist mit ausgeschriebenen bzw. abgekürzten Monats-/Tagesnamen? Natürlich nicht unbedingt nötig und erfordert evtl. sogar Lokalisierung, aber vielleicht auch eine Möglichkeit, es dem Nutzer einfacher zu machen.

Abgesehen davon scheint mir die KW üblicherweise seltener gebräuchlich zu sein als der Monat: MM.JJJJ wäre daher für den Monat, KW/JJJJ für die Kalenderwoche (oder KWnn.JJJJ, falls Du vor der Verwendung unterschiedlicher Feldtrenner zurückschreckst) eher angemessen.

Außerdem ist eine Verkürzung auf JJ eine durchaus zulässige Vereinfachung, solange man sich innerhalb klar definierter Grenzen (bspw. +/- 50 Jahre vom aktuellen Jahrzehnt) bewegt.

Eventuell kannst Du in der weiteren Behandlung der Eingabedaten den Benutzer darauf hinweisen, was er gerade macht und was er machen kann, bspw. wenn die Eingabe "15.2007" ist, ihn darauf hinweisen, dass er wahrscheinlich eine Kalenderwoche meint und nicht einen Monat.

Gruß, LX

[Horst]

hi,

Abgesehen davon scheint mir die KW üblicherweise seltener gebräuchlich zu sein als der Monat: MM.JJJJ wäre daher für den Monat, KW/JJJJ für die Kalenderwoche (oder KWnn.JJJJ, falls Du vor der Verwendung unterschiedlicher Feldtrenner zurückschreckst) eher angemessen.

Unterschiedliche Trenner: Gute Idee!

Außerdem ist eine Verkürzung auf JJ eine durchaus zulässige Vereinfachung, solange man sich innerhalb klar definierter Grenzen (bspw. +/- 50 Jahre vom aktuellen Jahrzehnt) bewegt.

Von solchen Vereinfachungen habe ich mich schon lange verabschiedet. Das Jahr 08 ist das Jahr 8 und das Jahr 65 ist eben das Jahr 65. Es mag im Tagesjargon noch funktionieren, dass mit dem Jahr 75 das Jahr 1975 gemeint ist aber nicht in Programmen die über Jahrtausende rechnen.

Allerdings, da hast Du schon recht, der Benutzer sollte darauf hingewiesen werden.

Eventuell kannst Du in der weiteren Behandlung der Eingabedaten den Benutzer darauf hinweisen, was er gerade macht und was er machen kann, bspw. wenn die Eingabe "15.2007" ist, ihn darauf hinweisen, dass er wahrscheinlich eine Kalenderwoche meint und nicht einen Monat.

Der Benutzer sollte schon vor der Eingabe wissen, in welchem Format er was eingibt,

3.1900 => Monat 3 1900
3/2008 => Kalenderwoche 3 2008

also vor der Verarbeitung der Eingabe. Er bekommt das Ergbnis ja dann auch zu sehen oder auch nicht, wenn das Eingabeformat micht passt ;)

Viele Grüße und danke für die Tipps von Allen hier!
Hotte

@Kalle, mit der Gregor. Kalenderreform sind keineswegs Tage verlorengegangen, es ist jedoch so, dass es ab dem 4.10.1582 nunmehr zwei Zählungen gibt:

Datum      JulianDay  JulianCount
4.10.1582  2299160    2299160
15.10.1582 2299161    2299171
16.10.1582 2299162    2299172

Joseph Justus Scaliger (5.8.1540 - 21.1.1609) begründete die fortlaufende Zählung der Tage ab dem Tag 0 am 1.1.4713 B.C. Einfach genial.

Wenn mein Frontend auf dem neuen WebSpace fertig ist, zeige ich es Euch gerne. Solange die Provider sich noch um den KK bemühen, hab ich ja noch genug Zeit.

[Beat]

Folgende Eingaben sind möglich:

• TT.MM.JJJJ (Einzelnes Datum, 1.1.2009, 1.1.-4711)
• Julianischer Tag numerisch (z.B.: 2524602)
• KW.JJJJ (Kalenderwoche, z.B.: 12.2008)
• TT.MM.JJJJ Tage( Datum und Anzahl von Tagen zum Addieren/Subtrahieren)
• TT.MM.JJJJ TT.MM.JJJJ (Zwei Tage zur Berechnung der Differenz zwischen Beiden)
• yJAHR (y2008, y2009, das JAHR wird ausgegeben)
• mMM.JJJJ (m1.1999, m2.2008, der Monat wird ausgegeben)

O.G. Vorteil ergibt sich außerdem auch aus der Tatsache, dass ich die Eingaben ohnehin prüfen muss, daher kam ich auf diese Idee, die ich für gut und benutzerfreundlich befinde.

Setze dein Eingabefeld in Relation zu einer Selektbox.
In der Selektbox bestimmt der Anwender das Eingabeformat.
Du hast in der Selektbox die Möglichkeit, Formate auszuführen.
Das lässt noch viel mehr Möglichkeiten zu als du jetzt dir ausdenkst.

mfg Beat

[Horst]

hi Beat,

Setze dein Eingabefeld in Relation zu einer Selektbox.
In der Selektbox bestimmt der Anwender das Eingabeformat.
Du hast in der Selektbox die Möglichkeit, Formate auszuführen.
Das lässt noch viel mehr Möglichkeiten zu als du jetzt dir ausdenkst.

die Idee ist prinzipell gut, aber damit hätte ich wieder ein Formularfeld mehr, was der Benutzer bedienen muss, was aber gar nicht notwendig ist, weil mein Programm anhand des Eingabeformats bereits erkennt, was der Benutzer berechnet haben will.

Viele Grüße vom Baumarkt,
Horst Haselhuhn

[Horst]

hi,

wer mag, kann ein bischen damit spielen:
http://rolfrost.de/cgi-bin/xdate.cgi

Viel Spaß damit,
Hotte

[Beat]

wer mag, kann ein bischen damit spielen:
http://rolfrost.de/cgi-bin/xdate.cgi
Viel Spaß damit,
Hotte

Wenn ich ein Jahr Eingebe <input>08</input>
Dann erhalte ich keinen Hinweis, auf welchem Kalendermodell der Output zu lesen ist.

<input08.8.-08</input> gibt ganz lustige Jahrbezeichnungen.
Im Output auf 4 stellige Jahrangaben zu beharren, deutet auf irgend eine Beschränkung hin.
Auch wird das Datum bei inkonsistentem Input wie hier nicht normalisiert.

Ich halte meinen Vorschlag für besser.
Der User gibt die Interpretation in einer Selkt Option vor. Du hast das Parsen einfacher und kannst zugleich mehr Funktionen über das gleiche Input anbieten.

An einer solchen Eingabe <input>9.09.2009</input> ist das Programm einige Zeit beschäftigt. Das liess sich wiederholen, nachdem ich dazwischen einen sauberen Input reingehackt habe.

Hacken macht Spass!

mfg Beat

[Horst]

wer mag, kann ein bischen damit spielen:
http://rolfrost.de/cgi-bin/xdate.cgi
Viel Spaß damit,
Hotte

Danke Beat,

Wenn ich ein Jahr Eingebe <input>08</input>
Dann erhalte ich keinen Hinweis, auf welchem Kalendermodell der Output zu lesen ist.

Das wird noch verbessert

<input08.8.-08</input> gibt ganz lustige Jahrbezeichnungen.

-08 ? meinst Du das? Nunja, das Jahr darf auch negativ sein (B.C.)

Im Output auf 4 stellige Jahrangaben zu beharren, deutet auf irgend eine Beschränkung hin.

Wird verbessert!

Auch wird das Datum bei inkonsistentem Input wie hier nicht normalisiert.

Wird verbessert.

Ich halte meinen Vorschlag für besser.
Der User gibt die Interpretation in einer Selkt Option vor. Du hast das Parsen einfacher und kannst zugleich mehr Funktionen über das gleiche Input anbieten.

Wird überschlafen...

An einer solchen Eingabe <input>9.09.2009</input> ist das Programm einige Zeit beschäftigt. Das liess sich wiederholen, nachdem ich dazwischen einen sauberen Input reingehackt habe.

Kann ich nicht nachvollziehen, das ist eine ungültige Eingabe und das CGI meldet das auch.

Ansonsten gibt es schon noch was zu tun :-)

Hotte

[Beat]

-08 ? meinst Du das? Nunja, das Jahr darf auch negativ sein (B.C.)

Tücke: -8 ist nicht 8BC sondern 7BC
Negaive Jahrwerte sind durchaus legitim, aber etwas komplett anderes als BC.

Ich halte meinen Vorschlag für besser.
Der User gibt die Interpretation in einer Selkt Option vor. Du hast das Parsen einfacher und kannst zugleich mehr Funktionen über das gleiche Input anbieten.

Wird überschlafen...

genehmigt :))

...<input>9.09.2009</input> ist das Programm einige Zeit beschäftigt. ..
Kann ich nicht nachvollziehen, das ist eine ungültige Eingabe und das CGI meldet das auch.

Ja 'ungültig' wird zurückgegeben. Aber es ist ein Hinweis, dass die RE Engine hier viel rechnen muss, um das zu entdecken.

mfg Beat

[Horst]

-08 ? meinst Du das? Nunja, das Jahr darf auch negativ sein (B.C.)

Tücke: -8 ist nicht 8BC sondern 7BC

Bei meinen Recherchen habe ich gesehen, dass dies unterschiedlich gehandhabt wird und so habe ich mich für _eine_ der beiden Interpretationen entschieden (geht ja auch nicht anders).

Nach Scaliger gelten folgende Vereinbarungen:
das Jahr 0 gibt es nicht
das Jahr -7 bezeichnet das Jahr 7 vor Christi (B.C.)
auf den 31.12.-1 folgt der 1.1.1
die Jahre im positiven Bereich heißen auch A.D. Anno Domini

Viele Grüße und danke nochmal!
Hotte

[Beat]

Tücke: -8 ist nicht 8BC sondern 7BC

Ich korrigiere mich gleich selbst

1AD = 1CE
1BC = 0CE
2BC = -1CE
..
9BC = -8CE

Bei meinen Recherchen habe ich gesehen, dass dies unterschiedlich gehandhabt wird und so habe ich mich für _eine_ der beiden Interpretationen entschieden (geht ja auch nicht anders).

Ui das ist aber nicht so willkürlich.
Entweder du verwendest CE (Common Era) und darfst dort negative Werte verwenden.
Oder du verwendest AD (Anno Dotalschaden) BC (Before Crisis)
Oder du verwendest CE Common Era) BCE (Before Common Era)

0CE = -1 BC = -1 BCE

Nach Scaliger gelten folgende Vereinbarungen:
das Jahr 0 gibt es nicht
das Jahr -7 bezeichnet das Jahr 7 vor Christi (B.C.)

Da wollte ich gerne die Referenz denn es ist so, dass das was man heute als Julian Day anpreist, in der jetzigen Form nicht von Scaliger ist

Da gibt's noch das Problem dass Astronomen wiederum einen modifizierten JD verwenden, weil die mit einem Tageswechsel mitten in ihrer Beobachtungsphase nichts anfangen können.

auf den 31.12.-1 folgt der 1.1.1

a) was, mag es auch irgendwo vorkommen, total falsch ist.
   Blödsinn soll man nicht propagieren.

b) Bei einem Jahreswechsel im Januar. der bei dir Stilschweigen als Grundlage genommen wird, aber eigentlich explizit erwähnt werden sollte.

die Jahre im positiven Bereich heißen auch A.D. Anno Domini

Sei konsistent.
Entweder (Common Era) CE/-CE oder CE/BCE oder AD/BC

mfg Beat

[Horst]

hi

Sei konsistent.
Entweder (Common Era) CE/-CE oder CE/BCE oder AD/BC

Ok, mach ich, ich lasse einfach das A.D. und das B.C. weg, das sind ehe alles Gewächse auf Scaligers Grab.

Was bleibt Lt. Scaliger:
das Jahr 0 gibt es nicht
dem 31.12.-1 folgt der 1.1.1

Die Berechnung des Julianischen Tages nach Scaliger funktioniert i.Ü. nur bis 4.10.1582.

Bei meinen Recherchen habe ich viele Formeln gefunden, aus diesen habe ich zwei gemacht, wobei die eine Formel den Scaliger weiterleben lässt (4.10.1582 und 15.10.1582 sind aufeinanderfolgende Tage, die fortlaufende Numerierung der Tage bleibt erhalten), damit stimmt auch die Berechnung des Julianischen Tages.

Viele Grüße und danke für Dein Interesse,
Hotte

[at]

Hallo.

Folgende Eingaben sind möglich:

Keine Feiertage?

Was meint denn Ihr dazu?

Schade.
MfG, at