input type date

[pl]

Hi, s. Thema.

ist es möglich ein eigenes Format da festzulegen und eine damit verbundene bestimmte Browseraktion?

Schließlich gibt es ja Locale und das CLDR Projekt was einer solchen Frage gerecht wird, also ungezählte Formate länderspezifisch vordefinieren. Schön wenn man das direkt im Browser nutzen könnte!

MfG

[Christian Kruse]

Hallo pl,

ist es möglich ein eigenes Format da festzulegen und eine damit verbundene bestimmte Browseraktion?

Nein. Das Anzeige-Format ist definiert durch das Locale des Browsers, das interne Format ist durch den HTML5-Standard vorgegeben.

LG,
CK

[pl]

hi,

ist es möglich ein eigenes Format da festzulegen und eine damit verbundene bestimmte Browseraktion?

Nein. Das Anzeige-Format ist definiert durch das Locale des Browsers, das interne Format ist durch den HTML5-Standard vorgegeben.

Ok, danke und MfG

[Rolf B]

Hallo pl,

warum willst Du das tun? Du befindest Dich auf der Anwenderseite, und der Anwender hat ein locale auf seinem PC aktiv, zu dem der Browser eine passende Darstellung anbieten sollte. Wenn der Anwender ein anderes Date-Format nutzen will, ist das eigentlich eine Sache für die Regionen-Einstellungen seines PC.

Warum willst Du serverseitig darauf Einfluss nehmen?

Rolf

[pl]

hi,

warum willst Du das tun?

Weil man sich schließlich auf ein bestimmtes Format festlegen muss sonst kann man die Daten nicht verarbeiten.

Warum willst Du serverseitig darauf Einfluss nehmen?

Nicht nur serverseitig. Sondern auch clientseitig.

MfG

[Gunnar Bittersmann]

@@pl

Weil man sich schließlich auf ein bestimmtes Format festlegen muss sonst kann man die Daten nicht verarbeiten.

Nein, muss man nicht. Das Format ist bereits festgelegt. Der Wert aus dem Eingabewert ist unabhängig von der Formatierung der Anzeige. Steht doch alles da, wo man es vermutet: in der HTML-Spezifikation. Click.

Nach „input element“ gesucht … Darunter: Date state (type="date") Click.

“If the user agent provides a user interface for selecting a date, then the value must be set to a valid date string representing the user’s selection.” Click.

LLAP 🖖

[pl]

Hi,

Weil man sich schließlich auf ein bestimmtes Format festlegen muss sonst kann man die Daten nicht verarbeiten.

Nein, muss man nicht. Das Format ist bereits festgelegt. Der Wert aus dem Eingabewert ist unabhängig von der Formatierung der Anzeige. Steht doch alles da, wo man es vermutet: in der HTML-Spezifikation. Click.

Nach „input element“ gesucht … Darunter: Date state (type="date") Click.

Das deckt nicht alle Anforderungen meiner Anwendung ab die auch mit negativen Jahren rechnen muss.

“If the user agent provides a user interface for selecting a date, then the value must be set to a valid date string representing the user’s selection.” Click.

Und siehe da, genau da stehs ja auch:

Dates before the year one or after the year 9999 in the Gregorian calendar cannot be represented as a datetime in this version of HTML.

MfG

[Gunnar Bittersmann]

@@pl

Das deckt nicht alle Anforderungen meiner Anwendung ab die auch mit negativen Jahren rechnen muss. […] Und siehe da, genau da stehs ja auch:

Dates before the year one or after the year 9999 in the Gregorian calendar cannot be represented as a datetime in this version of HTML.

Schreib ein Bugticket gegen die Spec, dass HTML Jahreszahlen gemäß ISO 8601 unterstützen soll.

LLAP 🖖

[pl]

@@Gunnar Bittersmann

Das deckt nicht alle Anforderungen meiner Anwendung ab die auch mit negativen Jahren rechnen muss. […] Und siehe da, genau da stehs ja auch:

Dates before the year one or after the year 9999 in the Gregorian calendar cannot be represented as a datetime in this version of HTML.

Schreib ein Bugticket gegen die Spec, dass HTML Jahreszahlen gemäß ISO 8601 unterstützen soll.

Nein. Weil: Mein Vorschlag ganz anders lautet.

Bis dahin sollten Browserhersteller ersteinmal lernen mit Locale richtig umzugehen.

MfG

[Gunnar Bittersmann]

@@pl

Bis dahin sollten Browserhersteller ersteinmal lernen mit Locale richtig umzugehen.

Das tun sie bereits.

LLAP 🖖

[pl]

@@pl

Bis dahin sollten Browserhersteller ersteinmal lernen mit Locale richtig umzugehen.

Das tun sie bereits.

Nein. Wenn sie das täten, könnte man das als HTML Designer ja mit type="LC_TIME" einstellen. Kann man aber nicht.

MfG

[Gunnar Bittersmann]

@@pl

Bis dahin sollten Browserhersteller ersteinmal lernen mit Locale richtig umzugehen.

Das tun sie bereits.

Nein. Wenn sie das täten, könnte man das als HTML Designer ja mit type="LC_TIME" einstellen. Kann man aber nicht.

Und das ist auch gut so. Deine Worte: „Eigentlich gehen mich die lokalen Browsereinstellungen eines Benutzers gar nichts an.“

LLAP 🖖

[pl]

hi

Bis dahin sollten Browserhersteller ersteinmal lernen mit Locale richtig umzugehen.

Das tun sie bereits.

Nein. Wenn sie das täten, könnte man das als HTML Designer ja mit type="LC_TIME" einstellen. Kann man aber nicht.

Und das ist auch gut so. Deine Worte: „Eigentlich gehen mich die lokalen Browsereinstellungen eines Benutzers gar nichts an.“

Doch, wenn man sie nutzen will schon. Das kann man aber nur indem man voraussetzen kann, daß ein Browser LC_TIME nutzt. Für den Benutzer wäre das transparent und serverseitig würde das lokale Format überhaupt keine Rolle mehr spielen.

MfG

PS/Idee: LC_CURRENCY in Bitcoin umrechnen sollte ein moderner Browser auch können.

[pl]

Hi Rolf,

also je mehr ich darüber nachdenke: Eigentlich gehen mich die lokalen Browsereinstellungen eines Benutzers gar nichts an. Er sollte schon das Format benutzen was ihm recht ist. Genau dafür sind Locale ja da.

Wenn wir bessere Browser hätten die mit Julianischen Tagen rechnen könnten gäbe es dieses Problem gar nicht.

MfG

[Gunnar Bittersmann]

@@pl

also je mehr ich darüber nachdenke: Eigentlich gehen mich die lokalen Browsereinstellungen eines Benutzers gar nichts an.

Richtig.

Er sollte schon das Format benutzen was ihm recht ist.

Richtig.

Genau dafür sind Locale ja da.

Richtig.

Das heißt aber nicht, dass der Client das Datum in einem beliebigen, von den Locale-Einstellungen des Nutzers abhängigen Format an den Server schicken soll.

LLAP 🖖

[pl]

hi

Das heißt aber nicht, dass der Client das Datum in einem beliebigen, von den Locale-Einstellungen des Nutzers abhängigen Format an den Server schicken soll.

Genau! Ein Browser könnte den Julianischen Tag daraus errechnen und genau diesen senden (Astronomisches Datum). Für was es wohl diese Standards alle gibt!?

Und kaum zu glauben was man damit alles machen könnte!

MfG

[Tabellenkalk]

Hallo,

Und kaum zu glauben was man damit alles machen könnte!

Hokuspoke? Äh Horoskope!

Gruß
Kalk

[Henry]

Hallo pl,

Und kaum zu glauben was man damit alles machen könnte!

Tatsächlich frage ich mich das schon die ganze Zeit. Wenn du nicht gerade einen Flux-Kompensator bauen willst oder anderswie auf Zeitreise, nee mal im Ernst: Was könnte man damit machen?

Gruss
Henry

[pl]

Hi,

Und kaum zu glauben was man damit alles machen könnte!

Tatsächlich frage ich mich das schon die ganze Zeit. Wenn du nicht gerade einen Flux-Kompensator bauen willst oder anderswie auf Zeitreise, nee mal im Ernst: Was könnte man damit machen?

Benutzerfeundliche Form's. Das ist doch genau das was hier ständig gepredigt wird!

MfG

[Felix Riesterer]

Lieber pl,

Form's.

was soll das Apostroph? Leidest Du gerade unter Apostrophitis?

Liebe Grüße,

Felix Riesterer.

[JürgenB]

Hallo Felix,

Form's.

was soll das Apostroph? Leidest Du gerade unter Apostrophitis?

genau, wenn schon, dann „dem Form sein“. 😎

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Form's.

was soll das Apostroph? Leidest Du gerade unter Apostrophitis?

genau, wenn schon, dann „dem Form sein“. 😎

„in Form sein“. Du bist es wohl gerade‽

LLAP 🖖

[MudGuard]

Hi,

Form's.

was soll das Apostroph? Leidest Du gerade unter Apostrophitis?

genau, wenn schon, dann „dem Form sein“. 😎

„in Form sein“. Du bist es wohl gerade‽

Ich bin nicht nur in Form, ich bin sogar Informatiker 😉

cu,
Andreas a/k/a MudGuard

[pl]

Lieber Felix'

Form's.

was soll das Apostroph? Leidest Du gerade unter Apostrophitis?

Bedaure, ich bin Stotterer.

Mf'G

[Felix Riesterer]

Lieber Rolf,

und der Anwender hat ein locale auf seinem PC aktiv, zu dem der Browser eine passende Darstellung anbieten sollte.

als in Deutschland lebender Muttersprachler hantiere ich in der Regel mit DD.MM.YYYY. Mein Firefox sollte also diese Form über die eingestellte locale für die Anzeige wählen. Tut er aber nicht. Offensichtlich kann ich das dort auch nicht einstellen (nimmt wohl User-spezifische OS-Einstellung). Also muss ich es in den Sprachfeatures meiner Webapplikation handhaben. Dort verwende ich <input type="text"> für das Datum, welches ich dann vom Server in dem für den User eingestellten Format (ja, ich mache das Format von der Sprache abhängig) entgegen nehme und verarbeite.

Wenn der Anwender ein anderes Date-Format nutzen will, ist das eigentlich eine Sache für die Regionen-Einstellungen seines PC.

Ach, eigentlich würde es mich sehr stören, wenn das Veröffentlichungsdatum eines Artikels auf einer englisch-sprachigen Seite nur aufgrund meiner locale plötzlich in DD.MM.YYYY angezeigt würde. Noch schlimmer wird das, wenn anstatt YYYY nur YY verwendet wird, dann wird es eventuell sogar noch mehrdeutig...

Warum willst Du serverseitig darauf Einfluss nehmen?

Weil ich als Mensch verschiedene locales habe, mein Client aber nur eine. In der einen Applikation will ich alles auf Englisch haben (auch Datumswerte!), in der anderen auf Deutsch. Das regle ich über die Einstellungen in der jeweiligen Applikation, nicht an meinem PC!

Liebe Grüße,

Felix Riesterer.

[Auge]

Hallo

als in Deutschland lebender Muttersprachler hantiere ich in der Regel mit DD.MM.YYYY. Mein Firefox sollte also diese Form über die eingestellte locale für die Anzeige wählen. Tut er aber nicht.

Verstehe ich nicht. Mein Firefox (58.0.2) zeigt unter Ubuntu 16.04 in einem Date-Feld die Beispielvorbelegung der Datumswerte in deutscher Reihenfolge an. Gesendet wird der Wert natürlich im ISO-Format. Die „Erklärung“ unterhalb des Feldes, das ISO-Format für die Eingabe zu benutzen, stammt aus der Zeit ohne <input type="date">. Die Erklärung wird demnächst verschwinden.

Tschö, Auge

[pl]

Hallo

als in Deutschland lebender Muttersprachler hantiere ich in der Regel mit DD.MM.YYYY. Mein Firefox sollte also diese Form über die eingestellte locale für die Anzeige wählen. Tut er aber nicht.

Verstehe ich nicht. Mein Firefox (58.0.2) zeigt unter Ubuntu 16.04 in einem Date-Feld die Beispielvorbelegung der Datumswerte in deutscher Reihenfolge an. Gesendet wird der Wert natürlich im ISO-Format.

Genau das ist ja das Problem daß verschiedene Formate gesendet werden und type=date ebendaran nichts ändert.

MfG

[Christian Kruse]

Hallo pl,

Genau das ist ja das Problem daß verschiedene Formate gesendet werden und type=date ebendaran nichts ändert.

Das ist ein Irrtum. <input type="date"> hat zwei Formate: ein Display format, das ist abhängig vom Locale des Users. Und ein internes Format, das ist immer YYYY-mm-dd, unabhängig vom Locale des Users. Das interne Format wird im value-Attribut erwartet und es ist auch das, was an den Server geschickt wird.

LG,
CK

[pl]

hi

Genau das ist ja das Problem daß verschiedene Formate gesendet werden und type=date ebendaran nichts ändert.

Das ist ein Irrtum. <input type="date"> hat zwei Formate: ein Display format, das ist abhängig vom Locale des Users. Und ein internes Format, das ist immer YYYY-mm-dd, unabhängig vom Locale des Users. Das interne Format wird im value-Attribut erwartet und es ist auch das, was an den Server geschickt wird.

Schön wärs ja! Aber leider macht das mein Browser ff:52.7.0 nicht. Also kann man sich eben nicht darauf verlassen.

MfG

[Christian Kruse]

Hallo pl,

Das ist ein Irrtum. <input type="date"> hat zwei Formate: ein Display format, das ist abhängig vom Locale des Users. Und ein internes Format, das ist immer YYYY-mm-dd, unabhängig vom Locale des Users. Das interne Format wird im value-Attribut erwartet und es ist auch das, was an den Server geschickt wird.

Schön wärs ja! Aber leider macht das mein Browser ff:52.7.0 nicht. Also kann man sich eben nicht darauf verlassen.

FF52 kann kein <input type="date">.

LG,
CK

[pl]

Hi

FF52 kann kein <input type="date">.

Ja, schön. Ich kann aber auch meinen Besuchern nicht vorschreiben welchen Browser sie benutzen sollen 😉

MfG

[Christian Kruse]

Hallo pl,

FF52 kann kein <input type="date">.

Ja, schön. Ich kann aber auch meinen Besuchern nicht vorschreiben welchen Browser sie benutzen sollen 😉

Kein Grund es den Leuten vorzuenthalten, deren Browser es unterstützt. Schonmal von progressive enhancement gehört? Oder von Polyfills? Es gibt diverse Wege, mit diesem Problem umzugehen.

LG,
CK

[pl]

hi,

FF52 kann kein <input type="date">.

Ja, schön. Ich kann aber auch meinen Besuchern nicht vorschreiben welchen Browser sie benutzen sollen 😉

Kein Grund es den Leuten vorzuenthalten, deren Browser es unterstützt. Schonmal von progressive enhancement gehört? Oder von Polyfills? Es gibt diverse Wege, mit diesem Problem umzugehen.

Das mag sein. Das Problem jedoch bleibt!

MfG

[Christian Kruse]

Hallo pl,

Das mag sein. Das Problem jedoch bleibt!

Ja, und es wird auch nicht weg gehen, auch in 10 Jahren nicht. So ist das halt in der Software-Entwicklung im allgemeinen und im Web speziell: du hast keine Kontrolle.

LG,
CK

[pl]

hi

Das mag sein. Das Problem jedoch bleibt!

Ja, und es wird auch nicht weg gehen, auch in 10 Jahren nicht. So ist das halt in der Software-Entwicklung im allgemeinen und im Web speziell: du hast keine Kontrolle.

Doch die hat man: Wenn man sie selbst in die Hand nimmt!

MfG

[Gunnar Bittersmann]

@@pl

Ja, und es wird auch nicht weg gehen, auch in 10 Jahren nicht. So ist das halt in der Software-Entwicklung im allgemeinen und im Web speziell: du hast keine Kontrolle.

Doch die hat man: Wenn man sie selbst in die Hand nimmt!

Du willst anstatt Webseiten/Webapps lieber Apps erstellen, die sich Nutzer runterladen und auf ihrem System installieren müssen?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Du willst anstatt Webseiten/Webapps lieber Apps erstellen, die sich Nutzer runterladen und auf ihrem System installieren müssen?

Die Kontrolle, die man in „Apps“ hat, ist geringer als man denkt.

LG,
CK

[pl]

hi

Ja, und es wird auch nicht weg gehen, auch in 10 Jahren nicht. So ist das halt in der Software-Entwicklung im allgemeinen und im Web speziell: du hast keine Kontrolle.

Doch die hat man: Wenn man sie selbst in die Hand nimmt!

Du willst anstatt Webseiten/Webapps lieber Apps erstellen, die sich Nutzer runterladen und auf ihrem System installieren müssen?

Nein. Es geht hier um serverseitige Prüfungen von Benutzereingaben.

MfG

[Mitleser]

Doch die hat man: Wenn man sie selbst in die Hand nimmt! Du willst anstatt Webseiten/Webapps lieber Apps erstellen, die sich Nutzer runterladen und auf ihrem System installieren müssen?

Ich verstehe ihn so, dass er es für besser hält, auf "type=date" zu verzichten und stattdessen "type=text" zu verwenden. Warum auch immer...

[Gunnar Bittersmann]

@@pl

Aber leider macht das mein Browser ff:52.7.0 nicht.

Warum nutzt du auch Firefox ESR?

Also kann man sich eben nicht darauf verlassen.

Ja, schön. Ich kann aber auch meinen Besuchern nicht vorschreiben welchen Browser sie benutzen sollen 😉

Du kannst ihnen nicht einmal vorschreiben und dich darauf verlassen, dass sie überhaupt einen Browser benutzen.

Du musst sowieso serverseitig prüfen, was da für eine Eingabe kommt und irgendwie darauf reagieren, wenn die Eingabe nicht im Format YYYY-MM-DD ist. Das kann das Ignorieren der Eingabe sein (wäre aber blöd für Nutzer, deren Browser <input type="date"> nicht unterstützt) oder der Versuch, daraus ein Datum zu lesen, und Rückfrage „Sie meinten den 16. März 2018? Habe ich das richtig verstanden?“

LLAP 🖖

[pl]

hi

Du musst sowieso serverseitig prüfen, was da für eine Eingabe kommt und irgendwie darauf reagieren, wenn die Eingabe nicht im Format YYYY-MM-DD ist. Das kann das Ignorieren der Eingabe sein (wäre aber blöd für Nutzer, deren Browser <input type="date"> nicht unterstützt) oder der Versuch, daraus ein Datum zu lesen, und Rückfrage „Sie meinten den 16. März 2018? Habe ich das richtig verstanden?“

Den Besucher mit nervigen Rückfragen belästigen? Nicht Dein Ernst oder!?

😉

[Henry]

Hallo pl,

Den Besucher mit nervigen Rückfragen belästigen? Nicht Dein Ernst oder!?

Das wäre allerdings kontraproduktiv. Ich verstehe allerdings immer noch nicht deine Motivation bei der ganzen Sache, gibt so viele Kalenderscripte dafür. Warum so "klassisch"?

Gruss
Henry

[pl]

hi

Den Besucher mit nervigen Rückfragen belästigen? Nicht Dein Ernst oder!?

Das wäre allerdings kontraproduktiv. Ich verstehe allerdings immer noch nicht deine Motivation bei der ganzen Sache, gibt so viele Kalenderscripte dafür. Warum so "klassisch"?

Weil man trotz alldieser schönen Scripts und type=date um eine serverseitige Prüfung nicht drumherum kommt.

MfG

[Mitleser]

Weil man trotz alldieser schönen Scripts und type=date um eine serverseitige Prüfung nicht drumherum kommt.

Nee, oder?! Echt jetzt?

[Henry]

Hallo pl,

Weil man trotz alldieser schönen Scripts und type=date um eine serverseitige Prüfung nicht drumherum kommt.

so siehts aus, deshalb egal wie der User es in seinem Browser eingibt, der einfachste Weg für ihn auch der Beste.

Gruss
Henry

[Sentinel]

Weil man trotz alldieser schönen Scripts und type=date um eine serverseitige Prüfung nicht drumherum kommt.

Man kommt bei Userinput NIEMALS um eine serverseitige Prüfung "drumherum". Alles andere ist grob fahrlässig.

Never trust a user input!

[pl]

Weil man trotz alldieser schönen Scripts und type=date um eine serverseitige Prüfung nicht drumherum kommt.

Man kommt bei Userinput NIEMALS um eine serverseitige Prüfung "drumherum". Alles andere ist grob fahrlässig.

Never trust a user input!

So isses. Das war auch nie die Frage. Die Frage war die, inwieweit man type=date zur Unterstützung dieses Prinzip's herannehmen kann bei gleichzeitiger Verbesserung der Benutzerfreundlichkeit. Und die Antworten auf diese Frage sind einfach nur erschreckend 😉

MfG

[Matthias Apsel]

Hallo pl,

So isses. Das war auch nie die Frage. Die Frage war die, inwieweit man type=date zur Unterstützung dieses Prinzip's herannehmen kann bei gleichzeitiger Verbesserung der Benutzerfreundlichkeit. Und die Antworten auf diese Frage sind einfach nur erschreckend 😉

Bei deinen Beiträgen kann keine Ansätze zur Verbesserung der Benutzerfreundlichkeit entdecken.

Bis demnächst
Matthias

[pl]

hi,

So isses. Das war auch nie die Frage. Die Frage war die, inwieweit man type=date zur Unterstützung dieses Prinzip's herannehmen kann bei gleichzeitiger Verbesserung der Benutzerfreundlichkeit. Und die Antworten auf diese Frage sind einfach nur erschreckend 😉

Bei deinen Beiträgen kann keine Ansätze zur Verbesserung der Benutzerfreundlichkeit entdecken.

Was man mit type=date eben auch nicht kann. Der Test im Chrome hat mir gereicht, aber das hast Du wahrscheinlich gar nicht gelesen. Für mich schafft type=date eine Barriere.

MfG

[peter]

Was man mit type=date eben auch nicht kann. Der Test im Chrome hat mir gereicht, aber das hast Du wahrscheinlich gar nicht gelesen.

input type=date lässt sich in meinem Chrome exakt so befüllen wie type=text und hat zusätzlich noch weitere Inputmöglichkeiten; ist das bei dir anders?

Für mich schafft type=date eine Barriere.

Wenn dann wäre die Barriere in Chrome zu suchen, nicht in der HTML-Spec.

[Gunnar Bittersmann]

@@Henry

Ich verstehe allerdings immer noch nicht deine Motivation bei der ganzen Sache, gibt so viele Kalenderscripte dafür. Warum so "klassisch"?

<input type="date"> ist modern. Klassisch daran ist der Ansatz, nicht vorhandene Browserfunktionalität nochmals nachzubauen.

Auf meinem Gerät will ich genau den Datepicker haben, den ich von meinem Gerät kenne (also mit dessen Bedienung vertraut bin) und der speziell für dieses Gerät konzipiert wurde (also auf diesem Gerät bestens funktioniert).

Auf dem iPhone also den hier:

und nicht irgendwas, was auf dem Desktop funktioniert, fürs Smartphone aber ungeeignet ist.

Dem von dir gezeigten Datepicker ist anzurechnen, dass er auch direkte Tastatureingaben erlaubt und dass er auch per Pfeiltasten bedienbar ist. Das allerdings nicht vollständig: mit Pfeil rechts/links geht’s tageweise, mit Pfeil hoch/runter wochenweise. Um einen Tag im Jahr 2020 anzugeben, drückt pl sich die Finger wund. (Andere geben ihn per Zifferntasten ein.)

Ich hab allerdings nicht reingehört, ob der auch per Screenreader bedienbar ist. – Ein weiterer Vorteil für <input type="date">: Browser-/Gerätehersteller sorgen für Barrierefreiheit. Bei Nichtfuntionieren werden sie mit Bugtickets überhäuft. Und ich würde denken, dass die solche Bugs eher fixen als irgendein Anbieter eines JavaScript-Datepickers.

LLAP 🖖

[Gunnar Bittersmann]

@@pl

… oder Versuch, daraus ein Datum zu lesen, und Rückfrage „Sie meinten den 16. März 2018? Habe ich das richtig verstanden?“

Den Besucher mit nervigen Rückfragen belästigen? Nicht Dein Ernst oder!?

Nicht „den Besucher“ (alle Besucher), sondern nur dann, wenn nötig. Also schonmal nicht bei den meisten, die einen aktuellen Browser verwenden.

Aber auch bei den anderen nicht immer. Wenn jemand in das Texteingabefeld (was Fallback in Browsern ist, die type="date" nicht unterstützen) „20.3.2018“ einträgt, kann man ohne weitere Nachfrage 2018-03-20 als Eingabedatum verwenden.

Bei „4/5/18“ hingegen muss nachgefragt werden, ob der 5. April 2018 oder der 4. Mai 2018 gemeint ist.

Nachtrag: Auch bei „18-03-19“, ob es nun der 19. März 2018 oder der 18. März 2019 sein soll.

LLAP 🖖

[pl]

hi gunnar,

ich habe jetzt mal type=date im Chrome ausprobiert. Um das Datum 01.03.0001 einzugeben habe ich 10 Minuten gebraucht. Ewig scrollen und einmal verklickt -- da beginnt das Spiel von vorn.

Das ist Pfui!

Konfirmationsdialoge: Da ist auch die Frage inwieweit ein Client das unterstützt denn das muss ja dem Anwender kommuniziert werden. Wenn die Rückfrage vom Server kommt, wäre das schonmal ein zusätzlicher Request.

Der Legacy JS Confirm~Dialog ist außerdem unterdrückbar ohne daß man hierzu die Einstellungsseite bemühen muss (diese Meldung nicht mehr anzeigen).

Also wenn man genauer hinguckt ist an der Empfehlung type=date zu verwenden nicht wirklich was dran an praktischem Nutzen.

MfG

[Gunnar Bittersmann]

@@pl

ich habe jetzt mal type=date im Chrome ausprobiert. Um das Datum 01.03.0001 einzugeben habe ich 10 Minuten gebraucht. Ewig scrollen und einmal verklickt -- da beginnt das Spiel von vorn.

Das ist Pfui!

Nein. Niemand hat behauptet, dass Datepicker das beste Mittel sind, um sich durch Jahre oder gar Jahrhunderte und Jahrtausende zu bewegen. Da bist du mit der Tastatur besser dran. “Just use the keyboard.”

LLAP 🖖

[Mitleser]

Wenn jemand in das Texteingabefeld „20.3.2018“ einträgt, kann man ohne weitere Nachfrage 2018-03-20 als Eingabedatum verwenden.

Da gehe ich noch mit. Passt.

Bei „4/5/18“ hingegen muss nachgefragt werden, ob der 5. April 2018 oder der 4. Mai 2018 gemeint ist. Auch bei „18-03-19“, ob es nun der 19. März 2018 oder der 18. März 2019 sein soll.

Bei aller Liebe zum Detail, aber man kann es auch übertreiben. Eine Meldung "Ey sorry, bitte das Datum im Format XYZ eingeben, ja!" ist im Zweifelsfall auch akzeptabel.

[Gunnar Bittersmann]

@@Mitleser

Bei „4/5/18“ hingegen muss nachgefragt werden, ob der 5. April 2018 oder der 4. Mai 2018 gemeint ist. Auch bei „18-03-19“, ob es nun der 19. März 2018 oder der 18. März 2019 sein soll.

Bei aller Liebe zum Detail, aber man kann es auch übertreiben. Eine Meldung "Ey sorry, bitte das Datum im Format XYZ eingeben, ja!" ist im Zweifelsfall auch akzeptabel.

Abwägungssache: Will man dem Nutzer Vorschriften machen oder will man ihr Freiheiten lassen und im Zweifelsfall nachfragen?

LLAP 🖖

[Mitleser]

Bei „4/5/18“ hingegen muss nachgefragt werden, ob der 5. April 2018 oder der 4. Mai 2018 gemeint ist. Auch bei „18-03-19“, ob es nun der 19. März 2018 oder der 18. März 2019 sein soll.

Bei aller Liebe zum Detail, aber man kann es auch übertreiben. Eine Meldung "Ey sorry, bitte das Datum im Format XYZ eingeben, ja!" ist im Zweifelsfall auch akzeptabel.

Abwägungssache: Will man dem Nutzer Vorschriften machen oder will man ihr Freiheiten lassen und im Zweifelsfall nachfragen?

Besser im Sinne der UX ist Dein Vorschlag schon, gar keine Frage! Nur bedeutet jedes Stück Code immer auch Entwicklungs- und Wartungsaufwand. Abwägungssache. In dem Fall finde ich: übertrieben. Selbst ohne die Existenz von "type=date" wäre ich der Meinung. Mit umso mehr.

[Gunnar Bittersmann]

@@Mitleser

Besser im Sinne der UX ist Dein Vorschlag schon, gar keine Frage! Nur bedeutet jedes Stück Code immer auch Entwicklungs- und Wartungsaufwand.

Der Job eines Entwicklers sollte immer sein, es dem Nutzer einfach zu machen; nicht, es sich selbst einfach zu machen.

Angesichts der Tatsache, dass die meisten Nutzer moderne Browser verwenden und demzufolge vom Format YYYY-MM-DD abweichende Eingaben nur von wenigen kommen, ist die Frage natürlich berechtigt, wieviel Aufwand man da reinstecken will.

LLAP 🖖

[Mitleser]

Der Job eines Entwicklers sollte immer sein, es dem Nutzer einfach zu machen; nicht, es sich selbst einfach zu machen.

Das ist mir zu pauschal. Erste Stunde Sozialkunde damals, sinngemäß: "Es gibt unbegrenzt Bedürfnisse, aber nur begrenzt Ressourcen". Das lässt sich schön auf die Anforderungen einer Webseite übertragen. Keine erreicht nie 100%. Alle beteiligten Entwickler haben ein begrenztes Zeitkontingent. Obendrein kosten die oftmals sogar Kohle. Also muss man Prioritäten setzen und abwägen, was wann wie gebaut wird.

Ich kann mich echt dem Eindruck nicht erwehren, dass Du mit tagtäglichem Projektgeschäft nix am Hut hast, das verändert natürlich die Perspektive 😉

[Gunnar Bittersmann]

@@Mitleser

Alle beteiligten Entwickler haben ein begrenztes Zeitkontingent. Obendrein kosten die oftmals sogar Kohle. Also muss man Prioritäten setzen und abwägen, was wann wie gebaut wird.

Ja. Zum Job des Produktmanagers gehört auch zu erkennen, dass eine nutzerfreundliche Seite mehr Umsatz generiert, sich mehr Entwicklungsaufwand also durchaus bezahlt macht. Und dann den Entwicklern dann zu sagen, dass es deren Job sein sollte, es dem Nutzer einfach zu machen; nicht, es sich selbst einfach zu machen. (The sweet spot – wir sprachen drüber.)

Ich kann mich echt dem Eindruck nicht erwehren, dass Du mit tagtäglichem Projektgeschäft nix am Hut hast

Dein Eindruck trügt – leider. 😉

LLAP 🖖

[Auge]

Hallo

als in Deutschland lebender Muttersprachler hantiere ich in der Regel mit DD.MM.YYYY. Mein Firefox sollte also diese Form über die eingestellte locale für die Anzeige wählen. Tut er aber nicht.

Verstehe ich nicht. Mein Firefox (58.0.2) zeigt unter Ubuntu 16.04 in einem Date-Feld die Beispielvorbelegung der Datumswerte in deutscher Reihenfolge an. Gesendet wird der Wert natürlich im ISO-Format.

Genau das ist ja das Problem daß verschiedene Formate gesendet werden und type=date ebendaran nichts ändert.

Dass das so generell, wie du es hier schreibst, nicht stimmt, wurde ja schon geschrieben. <input type="date"> ändert alles – wenn es denn vom Browser unterstützt wird (was laut caniuse.com für etwa 92% der erfassten Installationen zutrifft). Browser die das nicht können, wie z.B. der von dir ins Feld geführte Firefox 52.irgendwas, unterscheden sich an dieser Stelle in keinster Weise von einem IE6 oder Netscape 4.7, für die das ebenfalls gilt. Denen würde man die nicht vorhandene Unterstützung wohl nicht vorwerfen, über die spricht man aber auch nicht mehr. Auch der ESR-Firefox wird nächstens auf eine neue Version gebracht, womit <input type="date"> auch in der dann aktuellen Version funktioniert. Ein halbes Jahr später wird vermutlich niemand mehr an Firefox 52 ESR erinnern können.

Das ist also ein Problem, dass sich eingabeseitig demnächst so gut wie erledigt hat. Dann bleiben als letzte Verweigerer nämlich nur noch der Safari (warum eigentlich?), der IE und der Opera Mini mit (laut caniuse.com) zusammen aktuell etwa 8% Marktanteil übrig. Die serverseitige Prüfung muss eh erfolgen und erschlägt dabei auch die Eingaben aus diesen Verweigerern für jetzt und immer, aber das ist beileibe keine Neuigkeit und kein Problem.

Was bleibt zu sagen? Es gab immer Browser, die kein <input type="date"> unterstützten. Die Eingabeprüfung musste daher schon immer erfolgen und ist ein längst gelöstes Problem. Darüber muss man mMn, außer gegenüber Anfängern, absolut kein Wort mehr verlieren.

Tschö, Auge

[pl]

Hallo

als in Deutschland lebender Muttersprachler hantiere ich in der Regel mit DD.MM.YYYY. Mein Firefox sollte also diese Form über die eingestellte locale für die Anzeige wählen. Tut er aber nicht.

Verstehe ich nicht. Mein Firefox (58.0.2) zeigt unter Ubuntu 16.04 in einem Date-Feld die Beispielvorbelegung der Datumswerte in deutscher Reihenfolge an. Gesendet wird der Wert natürlich im ISO-Format.

Genau das ist ja das Problem daß verschiedene Formate gesendet werden und type=date ebendaran nichts ändert.

Dass das so generell, wie du es hier schreibst, nicht stimmt, wurde ja schon geschrieben. <input type="date"> ändert alles –

Nein. Weil es nämlich gar keinen type=date gibt. Diesen type mag es für Browser geben aber schon ab dem Transport~Layer ist das nur noch text. D.h., daß man auf eine serverseitige Prüfung ohnehin nicht verzichten kann, ergo ist type=text keine Unterstützung -- auch dann nicht wenn man sich auf ein einheitliches gesendetes Format verlassen könnte.

Chrome: Mit type=date das Datum 01.03.0001 einzugeben habe ich gefühlte 10 Minuten gebraucht!

Das ist nicht mehr zumutbar finde ich.

MfG

[Gunnar Bittersmann]

@@pl

Chrome: Mit type=date das Datum 01.03.0001 einzugeben habe ich gefühlte 10 Minuten gebraucht!

Ich gefühlte 10 Sekunden. In echt vermutlich weniger:

1. Eingabefeld fokussieren
2. „01“ eingeben. Cursor springt automatisch zum Monat.
3. „03“ eingeben. Cursor springt automatisch zum Jahr.
4. „0001“ eingeben. Fertig.

Niemand sagt, dass ein Datepicker immer die beste Eingabemöglichkeit ist. Und ein Datepicker muss andere Eingabemöglichkeiten (wie Tastatur) nicht ausschließen. Sollte auch nicht.

Das ist nicht mehr zumutbar finde ich.

Deine Unbedarftheit ist wirklich unzumutbar. 😏

LLAP 🖖

[pl]

hi,

Chrome: Mit type=date das Datum 01.03.0001 einzugeben habe ich gefühlte 10 Minuten gebraucht!

Ich gefühlte 10 Sekunden. In echt vermutlich weniger:

1. Eingabefeld fokussieren
2. „01“ eingeben. Cursor springt automatisch zum Monat.
3. „03“ eingeben. Cursor springt automatisch zum Jahr.
4. „0001“ eingeben. Fertig.

Niemand sagt, dass ein Datepicker immer die beste Eingabemöglichkeit ist. Und ein Datepicker muss andere Eingabemöglichkeiten (wie Tastatur) nicht ausschließen. Sollte auch nicht.

Das ist nicht mehr zumutbar finde ich.

Deine Unbedarftheit ist wirklich unzumutbar. 😏

Nein es liegt an meiner Behinderung. Bist nicht gerade Du derjenige der hier ständig barrierefreies Design predigt?

MfG

[Tabellenkalk]

Hallo,

4. „0001“ eingeben. Fertig.

da muss man drei führende Nullen eintragen? Das ist unzumutbar!elf

Gruß
Kalk

[pl]

Hi,

eine Vorbelegung des value ist mir bei type=date übrigens auch nicht gelungen. D.h., daß ein Benutzer das Datum nach jeder Aktion wieder neu eintragen muss.

MfG

[Christian Kruse]

Hallo pl,

eine Vorbelegung des value ist mir bei type=date übrigens auch nicht gelungen. D.h., daß ein Benutzer das Datum nach jeder Aktion wieder neu eintragen muss.

Nein, du musst es nur richtig machen.

LG,
CK

[pl]

Hi,

eine Vorbelegung des value ist mir bei type=date übrigens auch nicht gelungen. D.h., daß ein Benutzer das Datum nach jeder Aktion wieder neu eintragen muss.

Nein, du musst es nur richtig machen.

Nein, dann isses ja wieder in den anderen Browsern falsch 😉

MfG

[Gunnar Bittersmann]

@@pl

Nein, du musst es nur richtig machen.

Nein, dann isses ja wieder in den anderen Browsern falsch 😉

Unsinn.

LLAP 🖖

[Mitleser]

Chrome: Mit type=date das Datum 01.03.0001 einzugeben

WTF?! LOL

[Auge]

Hallo

<input type="date"> ändert alles –

Nein. Weil es nämlich gar keinen type=date gibt. Diesen type mag es für Browser geben aber schon ab dem Transport~Layer ist das nur noch text.

Hossa, mal was ganz Neues! Auf dem Transport sind schon immer alle Eingaben aus allen Formularelementen eines HTML-Dokuments nur noch Text. Das war nie anders.

D.h., daß man auf eine serverseitige Prüfung ohnehin nicht verzichten kann

Ja, natürlich. Niemand hat etwas anderes behauptet.

ergo ist type=text keine Unterstützung -- auch dann nicht wenn man sich auf ein einheitliches gesendetes Format verlassen könnte.

Wenn man nicht irgendwelche Spezialanwendungen in heutzutage im allgemeinen Gebrauch ungebräuchlichen Datumssystemen verwenden will, kann man sich – mit den hinlänglich beschriebenen Ausnahmen – sehr wohl auf das gelieferte Format verlassen.

Chrome: Mit type=date das Datum 01.03.0001 einzugeben habe ich gefühlte 10 Minuten gebraucht!

Das ist nicht mehr zumutbar finde ich.

Was du alles so findest. In Browsern ein heute im Alltag nicht mehr benutztes Datumssystem unterstützen zu sollen ist so, als ob Tankstellen Holz, Kohle und/oder Torf anbieten müssten, nur weil es irgendwann mal Straßenfahrzeuge mit Dampfantrieb gegeben hat.

Für solche Spezialitäten ist das System einfach nicht vorgesehen. Warum auch? Die Kalender der Maya oder Assyrer werden auch nicht unterstützt. So what? Außer dir gibt es nur wenige weitere Anwender dafür. Und die, die das julianische Datum tatsächlich professionell benutzen, werden das mit geeigneten Werkzeugen tun, die das Datumssystem unterstützen. Und zack, bumm, wech ist das Problem keines mehr.

Tschö, Auge

[Matthias Apsel]

Hallo Auge,

Hossa, mal was ganz Neues! Auf dem Transport sind schon immer alle Eingaben aus allen Formularelementen eines HTML-Dokuments nur noch Text. Das war nie anders.

Nicht mal das: Zeichenwurst.

Was du alles so findest. In Browsern ein heute im Alltag nicht mehr benutztes Datumssystem unterstützen zu sollen ist so, als ob Tankstellen Holz, Kohle und/oder Torf anbieten müssten, nur weil es irgendwann mal Straßenfahrzeuge mit Dampfantrieb gegeben hat.

+1

Bis demnächst
Matthias

[pl]

hallo,

Was du alles so findest. In Browsern ein heute im Alltag nicht mehr benutztes Datumssystem unterstützen zu sollen ist so, als ob Tankstellen Holz, Kohle und/oder Torf anbieten müssten, nur weil es irgendwann mal Straßenfahrzeuge mit Dampfantrieb gegeben hat.

Was bitte möchtest Du nun damit sagen? Um nicht Gregorianische Kalender geht es hier gar nicht. Wobei auch dem sein Vorgänger, der Julianische Kalender mit Tag, Monat und Jahr tut. Von diesem Typ her sind die also gleich in der Handhabe sprich UI. Und selbstverständlich kann man auch die Jahre v. Chr. als positive Jahre eingeben, das ist eine Sache der Vereinbarung und natürlich muss man das in der Anwendung auch irgenwo eingeben können.

MfG

[Rolf B]

Hallo Felix,

soweit habe ich nicht gedacht. Tja.

Aber die Sprache reicht noch nicht. Das Gebiet ist auch noch relevant, z.B. ist en_US mm/dd/yyyy und en_AU ist dd/mm/yyyy. So'n Driss.

Rolf

[Gunnar Bittersmann]

@@Rolf B

und der Anwender hat ein locale auf seinem PC aktiv, zu dem der Browser eine passende Darstellung anbieten sollte.

Es ist wohl eher die Spracheinstellung im Browser, nicht im OS. Jedenfalls beim Firefox: oben mein Firefox (deutsch), darunter mein FirefoxDeveloperEdition (englisch):

LLAP 🖖

[pl]

Danke für die Screenshots!

[pl]

Was den Transport betrifft:

c-Library time.h

Definiert einen abstrakten Datentyp wie folgt:

struct  tm {
    int tm_sec;
    int tm_min;
    int tm_hour;
    int tm_mday;
    int tm_mon;
    int tm_year;
    int tm_wday;
    int tm_yday;
    int tm_isdst;
};

und siehe da, diesen Datentyp gibt es 1:1 auch in PHP 😉

Was spricht also dagegen, wann immer auch Datumsangaben zu erfassen, zu speichern und zu übertragen sind, ganz einfach diesen überaus portablen Datentyp zu senden!?

MfG

[dedlfix]

Tach!

c-Library time.h

Definiert einen abstrakten Datentyp wie folgt:

Ein abstrakter Datentyp beschreibt ein Verhalten (das was), gibt aber keine Implementation vor (das wie). Ein Interface in der OOP ist beispielsweise ein abstrakter Datentyp, weil ein Interface typischerweise nur die Methodensignaturen definiert. Eine Klasse und auch ein struct als Verbundtyp sind hingegen konkrete Datentypen, weil bei ihnen auch eine Implementation, also das wie vorhanden ist.

struct  tm {
    int tm_sec;
    int tm_min;
    int tm_hour;
    int tm_mday;
    int tm_mon;
    int tm_year;
    int tm_wday;
    int tm_yday;
    int tm_isdst;
};

und siehe da, diesen Datentyp gibt es 1:1 auch in PHP 😉

Nein, den gibts es da nicht. Die Funktion strptime() gibt den PHP-Datentyp Array zurück. Die Keys darin entprechen mit einer Ausnahme den Namen der Mitglieder oben gezeigten Typs. Es gibt keinen Key namens tm_isdst, dafür aber "unparsed". Also auch kein 1:1.

Was spricht also dagegen, wann immer auch Datumsangaben zu erfassen, zu speichern und zu übertragen sind, ganz einfach diesen überaus portablen Datentyp zu senden!?

In deinem eigenen Mikrokosmos kannst du sowohl Begriffe unabhängig vom allgemein Üblichen verwenden als auch deine Daten formatieren, wie es dir beliebt. Aber wenn es zur Kommunikation mit anderen kommt, ist es vorteilhafter für eine reibungslose Informationsübermittlung, sich am Üblichen und an Standards zu orientieren.

dedlfix.

[pl]

Tach!

In deinem eigenen Mikrokosmos kannst du sowohl Begriffe unabhängig vom allgemein Üblichen verwenden als auch deine Daten formatieren, wie es dir beliebt. Aber wenn es zur Kommunikation mit anderen kommt, ist es vorteilhafter für eine reibungslose Informationsübermittlung, sich am Üblichen und an Standards zu orientieren.

So isses. Genau deswegen gibt es Standards. Und: Sie machen das Programmieren einfacher. In PHP z.B. würde ein einziger Aufruf der unpack() Funktion genügen um sämtliche Felder des time.h Datentypes in ein Array zu bekommen. Siehe auch

MfG

[dedlfix]

Tach!

Genau deswegen gibt es Standards. Und: Sie machen das Programmieren einfacher.

Dann würde ich sie aber auch nutzen. Diverse standardisierte Formate, ein Datum darzustellen, existieren und die Systeme sind darauf eingerichtet. Diese Struktur ist jedenfalls kein Standard und damit auch in vielen Systemen unbekannt.

In PHP z.B. würde ein einziger Aufruf der unpack() Funktion genügen um sämtliche Felder des time.h Datentypes in ein Array zu bekommen. Siehe auch

Aha, localtime() hat dann doch alle Felder. Aber diese Funktion ist mir bisher noch nicht in freier Wildbahn begegnet, deswegen kannte ich sie auch nicht. In PHP ist es üblich, mit den Unix-Timestamps zu arbeiten und den Funktionen, die darauf basieren. Der Unix-Timestamp an sich ist schon deutlich verbreiteter als diese Struktur. Zudem gibt es auch Parser und Formatierfunktionen von und zu den standardisierten Textformaten für Datums- und Zeitwerte. Hast du Funktionen entdeckt, die diese C-Struktur weiterverarbeiten, mindestens aber einlesen? Eine Zeitzoneninformation ist in der Struktur übrigens auch nicht enthalten.

Mir fällt zusammenfassend ein Wort ein: unzweckmäßig.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Diese Struktur ist jedenfalls kein Standard und damit auch in vielen Systemen unbekannt.

Falls du mit „diese Struktur“ das struct tm meinst: doch, das ist Teil des POSIX-Standards. Der sagt übrigens nicht, dass die Struktur so wie von PL beschrieben aussehen muss, sondern, wie in POSIX üblich, definiert ein paar Felder, die mindestens vorhanden sein müssen:

The <time.h> header shall declare the tm structure, which shall include at least the following members:

int    tm_sec   Seconds [0,60]. 
int    tm_min   Minutes [0,59]. 
int    tm_hour  Hour [0,23]. 
int    tm_mday  Day of month [1,31]. 
int    tm_mon   Month of year [0,11]. 
int    tm_year  Years since 1900. 
int    tm_wday  Day of week [0,6] (Sunday =0). 
int    tm_yday  Day of year [0,365]. 
int    tm_isdst Daylight Savings flag. 

The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available.

Siehe auch.

Der Unix-Timestamp an sich ist schon deutlich verbreiteter als diese Struktur.

Eine mutige Aussage, ich bezweifle allerdings, dass sie wahr ist.

Eine Zeitzoneninformation ist in der Struktur übrigens auch nicht enthalten.

Diese Struktur ist nicht für den Austausch oder den Transport von Zeit-Daten gedacht. Sie ist eine Schnittstelle zum System. Sie gibt entweder die Zeitinformationen in der konfigurierten Zeitzone an (wenn man localtime() verwendet) oder sie gibt die Zeitinformationen in UTC an (wenn man gmtime() oder so verwendet). pl hat nur mal wieder alles durcheinander gewürfelt, was er finden konnte.

Edit:

Mir fällt zusammenfassend ein Wort ein: unzweckmäßig.

Für den Austausch von Zeit-Daten? Ja, klar. Ist ja auch nicht dafür gedacht… es ist eine Low-level-API zum System.

LG,
CK

[dedlfix]

Tach!

Falls du mit „diese Struktur“ das struct tm meinst: doch, das ist Teil des POSIX-Standards.

Ja, darauf bezieht sich dieser Threadzweig. Inwieweit ist aber POSIX und diese Struktur im speziellen verbreitet, auch außerhalb der UNIX-Welt?

Der Unix-Timestamp an sich ist schon deutlich verbreiteter als diese Struktur.

Eine mutige Aussage, ich bezweifle allerdings, dass sie wahr ist.

Wer arbeitet denn mit dieser Struktur und vor allem als Austauschformat? Das war ja pls Motivation daran. Zumindest wollte ich das in dieser Hinsicht bewertet wissen.

Javascript scheint darauf intern zu basieren, denn das hat dieselbe eigenartige Angewohnheit, den Monat 0-basierend, den Tag aber ab 1 zu benummern.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Falls du mit „diese Struktur“ das struct tm meinst: doch, das ist Teil des POSIX-Standards.

Ja, darauf bezieht sich dieser Threadzweig. Inwieweit ist aber POSIX und diese Struktur im speziellen verbreitet, auch außerhalb der UNIX-Welt?

Auch Windows nutzt diese Struktur. Sämtliche Software, die die OS-APIs für das arbeiten mit Zeitwerten nutzt, nutzt direkt oder indirekt diese Struktur.

Der Unix-Timestamp an sich ist schon deutlich verbreiteter als diese Struktur.

Eine mutige Aussage, ich bezweifle allerdings, dass sie wahr ist.

Wer arbeitet denn mit dieser Struktur

So ziemlich jeder 😉

und vor allem als Austauschformat?

Du hast meinen Beitrag unzulässig verkürzt.

• Diese Struktur ist nicht für den Austausch oder den Transport von Zeit-Daten gedacht.

• Für den Austausch von Zeit-Daten? Ja, klar. Ist ja auch nicht dafür gedacht…

LG,
CK

[dedlfix]

Tach!

Wer arbeitet denn mit dieser Struktur

So ziemlich jeder 😉

C#- und .NET-Programmierer schon mal nicht. PHP-Programmierer üblicherweise auch nicht. PHP kann diese Struktur lediglich in ähnlicher Form als Array erzeugen, aber das war es dann auch.

und vor allem als Austauschformat?

Du hast meinen Beitrag unzulässig verkürzt.

Nö, denn ich bezog mich auf deinen Einspruch, der eher auf Interna als auf Austausch abzielte. Den Rest des Postings habe ich sehr wohl zur Kenntnis und als Bestätigung meiner Meinung aufgefasst, ihn aber nicht weiter kommentiert, weil ich dem nichts hinzuzufügen habe.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Wer arbeitet denn mit dieser Struktur

So ziemlich jeder 😉

C#- und .NET-Programmierer schon mal nicht.

Das kann ich tatsächlich nicht belegen, dazu müsste ich mir jetzt die Sourcen der VM anschauen. Aber es würde mich wundern, wenn diese Aussage wahr wäre.

PHP-Programmierer üblicherweise auch nicht.

PHP-Programmierer verwenden sie häufig. Beachte das „direkt oder indirekt,“ diese Formulierung habe ich nicht zum Spass verwendet.

und vor allem als Austauschformat?

Du hast meinen Beitrag unzulässig verkürzt.

Nö, […]

Du hast einen Sinn in mein Posting gelegt, der so nicht zu erkennen war, erst recht nicht mit dem Zusatz, den du weg gelassen hast. Damit ist die Verkürzung unzulässig gewesen.

LG,
CK

[dedlfix]

Tach!

Wer arbeitet denn mit dieser Struktur

So ziemlich jeder 😉

C#- und .NET-Programmierer schon mal nicht.

Das kann ich tatsächlich nicht belegen, dazu müsste ich mir jetzt die Sourcen der VM anschauen. Aber es würde mich wundern, wenn diese Aussage wahr wäre.

Jemand der Programme in C# schreibt, verwendet die .NET-Struktur DateTime. Die entspricht gar nicht der C-Struktur, außer den Gemeinsamkeiten, die so ein Datums- und Zeitwert von Natur aus mitbringen, sprich: "hat ein Feld für Tag" usw. Das was irgendwie unter der Haube stattfindet, ist unsichtbar und steht auf einem ganz anderen Blatt.

PHP-Programmierer üblicherweise auch nicht.

PHP-Programmierer verwenden sie häufig. Beachte das „direkt oder indirekt,“ diese Formulierung habe ich nicht zum Spass verwendet.

Hab ich überlesen, in der Tat. Das indirekte nützt mir als Programmierer nur nichts. Deswegen traf ich meine Aussagen auch nicht anhand dieses verdeckten Kriteriums.

Du hast einen Sinn in mein Posting gelegt, der so nicht zu erkennen war, erst recht nicht mit dem Zusatz, den du weg gelassen hast. Damit ist die Verkürzung unzulässig gewesen.

So ähnlich habe ich es auch empfunden. Nicht weiter tragisch, das passiert eben, wenn als Kommunikationsmedium eine Sprache dient, die anders als die Programmiersprachen, viel Interpretationsspielraum lässt und die Empfangsgeräte (a.k.a. Sinnesorgane und Gehirn) weder nach einem einheitlichen Muster arbeiten, noch Prüfsummen heranziehen können, die das Empfangene tatsächlich als dem Abgesendeten entsprechend bestätigen könnten.

Meinen Satz "Wer arbeitet denn mit dieser Struktur und vor allem als Austauschformat?" habe ich auch als Einheit angesehen, und du hast ihn mir zerpflückt und die Teile unabhängig voneinander beantwortet. Das wäre nach deiner Definition eigentlich auch unzulässig.

---

P.S. Das Edit aus deiner ersten Antwort ist mir auch erst jetzt aufgefallen. Solche nachträglichen Änderungen, die nicht nur einfache Fehlerkorrekturen sind, sollte man lieber vermeiden. Das ist mir in den letzten Tagen auch mit zwei anderen Forumsteilnehmern passiert, dass nachdem ich das Posting gelesen hatte, noch inhaltliche Hinzufügungen vorgenommen wurden, die ich nur zufällig gefunden habe. Eventuell könnte man in der nächsten Version eine Möglichkeit einbauen, ein "geändert nach letztem Lesezugriff" kennzeichnen zu können?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Das was irgendwie unter der Haube stattfindet, ist unsichtbar und steht auf einem ganz anderen Blatt.

Um genau dieses Blatt ging es mir 😉 dass struct tm bei den meisten modernen Programmiersprachen nicht mehr direkt verwendet wird, ist mir bewusst, und das ist auch gut so. Mir ging es allerdings um die Verallgemeinerung, die du getroffen hast, und die ich so in der Form für argh mutig hielt: ich hätte mich nicht getraut, das mit einem Anspruch auf Korrektheit so zu schreiben.

Du hast einen Sinn in mein Posting gelegt, der so nicht zu erkennen war, erst recht nicht mit dem Zusatz, den du weg gelassen hast. Damit ist die Verkürzung unzulässig gewesen.

So ähnlich habe ich es auch empfunden.

Das tut mir leid, denn so war es nicht gemeint. Ich hatte ja absichtlich auch in zwei weiteren Punkten dir zugestimmt, damit eben genau der Eindruck nicht entsteht; denn deiner Grundaussage stimme ich ja durchaus zu. struct tm ist für den Austausch, ja sogar für die Speicherung von Zeit-Daten ungeeignet und war auch nie dazu gedacht.

Nicht weiter tragisch, das passiert eben, wenn als Kommunikationsmedium eine Sprache dient, die anders als die Programmiersprachen, viel Interpretationsspielraum lässt und die Empfangsgeräte (a.k.a. Sinnesorgane und Gehirn) weder nach einem einheitlichen Muster arbeiten, noch Prüfsummen heranziehen können, die das Empfangene tatsächlich als dem Abgesendeten entsprechend bestätigen könnten.

Da hast du vermutlich recht, ja.

Meinen Satz "Wer arbeitet denn mit dieser Struktur und vor allem als Austauschformat?" habe ich auch als Einheit angesehen, und du hast ihn mir zerpflückt und die Teile unabhängig voneinander beantwortet. Das wäre nach deiner Definition eigentlich auch unzulässig.

Naja, ich habe nichts weg gelassen, sondern nur getrennt voneinander geantwortet, um klarzustellen, dass es mir um einen anderen Aspekt ging. Aber es war etwas nickelig, ja 😝

P.S. Das Edit aus deiner ersten Antwort ist mir auch erst jetzt aufgefallen. Solche nachträglichen Änderungen, die nicht nur einfache Fehlerkorrekturen sind, sollte man lieber vermeiden.

Den Kampf hast du bereits verloren. Das musste ich auch schon einsehen. Das Edit-Feature existiert und wird so verwendet werden, zum Leidwesen des einen und zur Freude des anderen.

Eventuell könnte man in der nächsten Version eine Möglichkeit einbauen, ein "geändert nach letztem Lesezugriff" kennzeichnen zu können?

Die Idee gefällt mir. Vielleicht magst du das ja reporten?

LG,
CK

[dedlfix]

Tach!

Das was irgendwie unter der Haube stattfindet, ist unsichtbar und steht auf einem ganz anderen Blatt.

Um genau dieses Blatt ging es mir 😉 dass struct tm bei den meisten modernen Programmiersprachen nicht mehr direkt verwendet wird, ist mir bewusst, und das ist auch gut so. Mir ging es allerdings um die Verallgemeinerung, die du getroffen hast, und die ich so in der Form für argh mutig hielt: ich hätte mich nicht getraut, das mit einem Anspruch auf Korrektheit so zu schreiben.

Ich hatte diese Verallgemeinerung nicht im Sinne, also inklusive der Interna von Systemen, mit denen der Verwender nicht in Berührung kommt. Vielleicht habe ich das nicht so klar einschränkend formuliert, weil es für mich im Thema dieses Teilthreads um das Verwenden dieser Struktur ging. Der Rest war dann ein kleines Missverständnis, das wir nun wohl geklärt haben.

Ich hatte ja absichtlich auch in zwei weiteren Punkten dir zugestimmt, damit eben genau der Eindruck nicht entsteht; denn deiner Grundaussage stimme ich ja durchaus zu.

Den Teil empfand ich auch nicht als strittig.

dedlfix.

[pl]

Eure ganze Diskussion zeigt auch nur, daß ihr meinen Artikel gar nicht gelesen habt, was ich sehr schade finde. Die eingebauten Demos zeigen nämlich sehr schön, für was eine Typisierung gut ist und was man damit machen kann.

Eine angewandte Typisierung führt u.a. sowohl physikalisch als auch logisch sowie programmiertechnisch zu einer besseren Trennung der Datenobjekte, was mit den herkömmlichen Content-Types application/x-www-form-urlencoded und multipart/form-data gar nicht möglich ist!

Wenn wir bessere Browser hätten, wäre dies alles vom Client bis zum Server transparent.

Schönen Tach auch.

[MudGuard]

Hi,

denn das hat dieselbe eigenartige Angewohnheit, den Monat 0-basierend, den Tag aber ab 1 zu benummern.

Das dürfte aus der Zeit knappen Speichers und knapper Rechenleistung kommen.

Monate haben Namen, die Tage im Monat nicht.

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

Und nachdem sich das damals dann an viele Stellen verbreitet hat, wollte das keiner mehr umstellen, weil dann viele Stellen hätten geändert werden müssen.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Hi,

denn das hat dieselbe eigenartige Angewohnheit, den Monat 0-basierend, den Tag aber ab 1 zu benummern.

Das dürfte aus der Zeit knappen Speichers und knapper Rechenleistung kommen.

Ich würde eher „nicht nachgedacht“ als Ursache vermuten.

Monate haben Namen

Die man selten braucht, da man Daten in den allermeisten Fällen in der Kurzform mit Monat in Ziffern ausgibt.

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

*gähn*

Und nachdem sich das damals dann an viele Stellen verbreitet hat, wollte das keiner mehr umstellen, weil dann viele Stellen hätten geändert werden müssen.

Das ist wohl leider wahr.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

denn das hat dieselbe eigenartige Angewohnheit, den Monat 0-basierend, den Tag aber ab 1 zu benummern.

Das dürfte aus der Zeit knappen Speichers und knapper Rechenleistung kommen.

Ich würde eher „nicht nachgedacht“ als Ursache vermuten.

Ja, ich würde legacy auch als Grund vermuten.

Monate haben Namen

Die man selten braucht, da man Daten in den allermeisten Fällen in der Kurzform mit Monat in Ziffern ausgibt.

Zumal es ja auch tm_yday gibt, der den Wertebereich 0-365 hat. Für den Tag des Jahres aber gibt es keinen string index.

LG,
CK

[pl]

Hi,

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

Wo sollte da Speicherplatz gespart werden? In Programmen (RAM) hat jede Variable einen eigenen Speicherplatz wenn das nicht so wäre gäbe es keinen wahlfreien Zugriff. Und auch eine 0 braucht entsprechend des Datentype Speicher, im Falle des tm structs sogar 2 Byte.

MfG

[Christian Kruse]

Hallo pl,

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

Wo sollte da Speicherplatz gespart werden?

const char *mon_names[] = {"Jan", "Feb", /* ... */ };
const char *mon_names_1[] = { NULL, "Jan", "Feb", /* ... */ };

mon_names braucht auf aktuellen Prozessor-Architekturen 8 byte weniger als mon_names_1.

LG,
CK

[pl]

Hallo pl,

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

Wo sollte da Speicherplatz gespart werden?

const char *mon_names[] = {"Jan", "Feb", /* ... */ };
const char *mon_names_1[] = { NULL, "Jan", "Feb", /* ... */ };

mon_names braucht auf aktuellen Prozessor-Architekturen 8 byte weniger als mon_names_1.

Das hat aber nichts mit dem tm struct zu tun. MfG

[Christian Kruse]

Hallo pl,

Das hat aber nichts mit dem tm struct zu tun. MfG

Mudguard schrieb über den Array mit Monatsnamen.

Mit dem 0-basierten Monat spart man den Speicherplatz für das (überflüssige) 0. Element im Array der Monatsnamen oder die Umrechnung des Index im Array monatsnamen[monat-1].

Nächstes mal nochmal nachlesen.

LG,
CK

[pl]

hi

Das hat aber nichts mit dem tm struct zu tun. MfG

Mudguard schrieb über den Array mit Monatsnamen.

Ja, schon klar. NULL jedoch ist ein Zeiger und kein Arrayelement. MfG

[Christian Kruse]

Hallo pl,

Das hat aber nichts mit dem tm struct zu tun. MfG

Mudguard schrieb über den Array mit Monatsnamen.

Ja, schon klar. NULL jedoch ist ein Zeiger und kein Arrayelement. MfG

const char *[] ist ein Array von char-Pointern. NULL ist hier ganz klar ein Element des Arrays und belegt sizeof(char *), was bei modernen CPUs halt 64 Bit = 8 Byte sind.

➜ ckruse@spinnweb ~  % cat test.c
#include <stdlib.h>
#include <stdio.h>

int main(void) {
  const char *mon_names[] = {"Jan", "Feb", /* ... */ };
  const char *mon_names_1[] = { NULL, "Jan", "Feb", /* ... */ };

  printf("mon_names:%lu vs mon_names_1:%lu\n", sizeof(mon_names), sizeof(mon_names_1));

  return 0;
}

➜ ckruse@spinnweb ~  % gcc -Wall -o test test.c
➜ ckruse@spinnweb ~  % ./test
mon_names:16 vs mon_names_1:24
➜ ckruse@spinnweb ~  %

LG,
CK

[pl]

war mir neu, danke.

[pl]

war mir neu, danke.

Hi CK,

PS, ich hab mal gelernt, daß der NULL Pointer ja gar kein Pointer ist weil er auf keine Speicheradresse zeigt. Vielmehr ist der NULL Pointer nur eine Konvention/Vereinbarung/Festlegung und deswegen auch kein numerischer Datentyp wie alle anderen Pointer die auf reelle Speicheradressen zeigen und bspw. vom Typ Int32 sein müssen wenn ein 32~Bit~OS darunterliegt.

MfG

[Matthias Apsel]

Hallo pl,

PS, ich hab mal gelernt, daß der NULL Pointer ja gar kein Pointer ist weil er auf keine Speicheradresse zeigt. Vielmehr ist der NULL Pointer nur eine Konvention/Vereinbarung/Festlegung und deswegen auch kein numerischer Datentyp wie alle anderen Pointer die auf reelle Speicheradressen zeigen und bspw. vom Typ Int32 sein müssen wenn ein 32~Bit~OS darunterliegt.

Was möchtest du damit sagen?

Bis demnächst
Matthias

[pl]

hi

PS, ich hab mal gelernt, daß der NULL Pointer ja gar kein Pointer ist weil er auf keine Speicheradresse zeigt. Vielmehr ist der NULL Pointer nur eine Konvention/Vereinbarung/Festlegung und deswegen auch kein numerischer Datentyp wie alle anderen Pointer die auf reelle Speicheradressen zeigen und bspw. vom Typ Int32 sein müssen wenn ein 32~Bit~OS darunterliegt.

Was möchtest du damit sagen?

Daß die hier getroffene Aussage von CK zur Disposition steht.

Möchtest Du etwas dazu beitragen?

MfG

[Matthias Apsel]

Hallo pl,

Daß die hier getroffene Aussage von CK zur Disposition steht.

Wenn ich das richtig verstehe hat Christian die Richtigkeit seiner Aussage zwei Beiträge später für einen konkreten Fall nachgewiesen.

Möchtest Du etwas dazu beitragen?

Könnte es auch sein, dass das, was du mal gelernt hast, inzwischen überholt ist?

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Möchtest Du etwas dazu beitragen?

Könnte es auch sein, dass das, was du mal gelernt hast, inzwischen überholt ist?

Es hat noch nie gestimmt… duck

LG,
CK

[Christian Kruse]

Hallo pl,

Daß die hier getroffene Aussage von CK zur Disposition steht.

Du kannst sie gerne zur Disposition stellen, allerdings wird das wohl schwer werden. Außergewöhnliche Behauptungen erfordern außergewöhnliche Nachweise. Und da ich dir nachweisen konnte, dass ein Pointer auf modernen Prozessoren 64 Bit belegt, auch wenn er den Wert 0 hat, brauchst du sehr außergewöhnliche Nachweise 😜

LG,
CK

[pl]

hi

Daß die hier getroffene Aussage von CK zur Disposition steht.

Du kannst sie gerne zur Disposition stellen, allerdings wird das wohl schwer werden. Außergewöhnliche Behauptungen erfordern außergewöhnliche Nachweise. Und da ich dir nachweisen konnte, dass ein Pointer auf modernen Prozessoren 64 Bit belegt, auch wenn er den Wert 0 hat, brauchst du sehr außergewöhnliche Nachweise 😜

Das hab ich auch gar nicht bestritten. MfG

[Matthias Apsel]

Hallo pl,

Daß die hier getroffene Aussage von CK zur Disposition steht.

Du kannst sie gerne zur Disposition stellen, allerdings wird das wohl schwer werden. Außergewöhnliche Behauptungen erfordern außergewöhnliche Nachweise. Und da ich dir nachweisen konnte, dass ein Pointer auf modernen Prozessoren 64 Bit belegt, auch wenn er den Wert 0 hat, brauchst du sehr außergewöhnliche Nachweise 😜

Das hab ich auch gar nicht bestritten.

Was hast du gar nicht bestritten?

Bis demnächst
Matthias

[pl]

Die Diskussion wird schon wieder sinnlos!

[Christian Kruse]

Hallo pl,

Die Diskussion wird schon wieder sinnlos!

Da stimme ich dir zu.

LG,
CK

[Christian Kruse]

Hallo pl,

PS, ich hab mal gelernt, daß der NULL Pointer ja gar kein Pointer ist

Das ist richtig, es ist ein Wert. Ein Wert, den ein Pointer annehmen kann bzw der einem Pointer zugewiesen werden kann.

weil er auf keine Speicheradresse zeigt.

Das ist nur halb richtig. Speicheradresse Null existiert, allerdings wird sie vom OS reserviert und geschützt. Das ist übrigens auch nicht immer so gewesen.

Vielmehr ist der NULL Pointer nur eine Konvention/Vereinbarung/Festlegung und deswegen auch kein numerischer Datentyp wie alle anderen Pointer die auf reelle Speicheradressen zeigen und bspw. vom Typ Int32 sein müssen wenn ein 32~Bit~OS darunterliegt.

Das ist, mit Verlaub, großer Bullshit. Wenn ich einem Pointer den Wert NULL zuweise: char *ptr = NULL, dann wird der Speicher, den ptr belegen muss um eine Speicheradresse speichern zu können, nicht magisch freigegeben. ptr belegt immer sizeof(char *) Byte, was idR halt der Architektur-Breite entspricht. Auf 32-Bit-Systemen also 4 byte, auf 64-Bit-Systemen also 8 Byte. Die Größe einer Variablen, die sie im Speicher belegt, ändert sich nicht abhängig vom Wert.

LG,
CK

[pl]

Es geht hier nicht um Zweckmäßigkeiten. Ich publiziere ja nur Dinge die es auch ohne mich gibt, was der Leser damit macht kann er gerne für sich selbst entscheiden.

Diese Demo /am Ende der Seite/ zeigt sehr schön, wie Sinnvoll eine Typisierung ist als Basis für plattformübergeifenden Datenaustausch.

MfG

[Gunnar Bittersmann]

@@pl

Es geht hier nicht um Zweckmäßigkeiten. Ich publiziere ja nur Dinge die es auch ohne mich gibt, was der Leser damit macht kann er gerne für sich selbst entscheiden.

Mit anderen Worten: Du publizierst Dinge, die überhaupt nicht zweckmäßig sind. Ein Leser, der noch weniger Ahnung hat als du, soll damit machen was er will.

Das kommt der Empfehlung gleich, alle deine Postings zu ignorieren.

LLAP 🖖

[pl]

hi,

Es geht hier nicht um Zweckmäßigkeiten. Ich publiziere ja nur Dinge die es auch ohne mich gibt, was der Leser damit macht kann er gerne für sich selbst entscheiden.

Mit anderen Worten: Du publizierst Dinge, die überhaupt nicht zweckmäßig sind. Ein Leser, der noch weniger Ahnung hat als du, soll damit machen was er will.

Diese Demo zeigt dem Leser was er damit machen kann, ein paar Grundkenntnisse sollten da schon vorhanden sein.

Praktisch transportiert HTTP ein Array mit numerischen Datentypen und zur Wiederherstellung des Arrays genügt es, eine diesen Datentypen entsprechende Schablone auf die Binary zu legen.

Das sollte sogar ein Laie verstehen. MfG

[pl]

Hier ganz unten ist eine DEMO zum Ausprobieren.

MfG