Filter fromTo - gesamten Tag ("day") filtern

[tschupatschups]

Hallo,

wird beim Filter FromTo nur das Schema "Datum" ausgewählt, wird beim Filtern die aktuelle Uhrzeit verwendet.
Das Problem ist, dass beim Filter derzeit aber so nicht alle Termine des gesamten Tages ausgegeben werden.

Beispiel:
Es gibt einen Termin am 02.01.2015 um 14:00 Uhr.
(Termin im Backend mit Zeitangabe gespeichert, da für die Ausgabe benötigt).

Ein User benutzt den FrontendFilter zu Mittag um 12.10 Uhr und filtert Termine zwischen 01.01.2015 und 02.01.2015.
Im Frontend gibt es beim Filter keine Zeitangabe - es sollen alle Termine des gesamten Tages angezeigt werden.

Das Problem ist, das der Filter nun alle Termine von 01.01.2015 12:10 bis 02.01.2015 12.10 filtert und somit den gesuchten Termin nicht anzeigt.

Wäre es nicht sinnvoll bei evaluateLowerBound() und evaluateUpperBound() den Beginn bzw. das Ende des Tages im timestamp festzulegen?

$this->lowerBound = ( strtotime(date("Ymd", $this->lowerBound)) );

$this->upperBound = ( strtotime(date("Ymd", $this->upperBound) . ' 23:59:59') );

Und evtl. im DCA noch 2 Checkboxen hinzuzufügen für "Ab 0 Uhr" / " Bis 23:59:59" filtern.

Evtl. übersehe ich auch eine andere Möglichkeit so einen Filter umzusetzen.

[discordier]

Nein, du hast recht. Ein solches Feature ist sinnvoll.

[zonky2]

ich bin eher der Meinung, man sollte Daten als solches Speichern was sie sind - also Datum bzw. Datum-Zeit als die MySQL-Werte -> siehe MetaModels/core#881

... aber das scheint eher in den Bereich "philosophische Ansicht" zu gehen...

[discordier]

Und wir werden damit inkompatibel zu Contao. Die Idee hatten wir schon lange, aber aus genau diesem Grund bislang nicht verfolgt.

[zonky2]

bedeutet ja nicht, dass es Contao nicht auch "besser" machen könnte ;-)

[discordier]

Was aber nicht uns obliegt zu entscheiden...

[zonky2]

... wobei mir auf die Schnelle es nicht einleuchtet, bei bzw. für was hier eine "Kompatibilität" notwendig wäre - ggf. wenn man aus MM z.B. auf tl_events zugreift... wobei ich mir für den Fall die hin/her-Konvertierung von/zum Timestamp nicht sehr schwer vorstelle...

[discordier]

Was bedeutet dass der Code jedesmal in der DB nachsehen muss was man denn gerade fyr ein Feld hat.

[zonky2]

der Timestamp kann nur ein INT sein - MySQL date bzw. datetime nicht

[discordier]

Exakt, du hast das Problem erkannt.

[zonky2]

dann ist es doch nicht schwer, eine (eindeutige) Fallunterscheidung zu machen

[discordier]

Eben gerade deshalb schon.
Du musst die Datenbank analysieren um zu raten was nun drin ist. Es koennte int, date, time oder datetime sein.
Dann muss man dies immer in int wandeln, damit der Contao Core damit arbeiten kann und wieder ins native wandeln wenn es in die Datenbank zuryck soll.
Danach zu filtern bzw. darin zu suchen muss ebenfalls diese Wandlungen vornehmen.

[zonky2]

das Umwandeln in INT soll ja vermieden werden - für den heutigen Tag gibt es genau einen Wert: 25.01.2016 vs. bei Timestamp (INT) gibt es mehrere Werte (86400) aus denen das "berechnet" werden kann

[discordier]

Contao versteht aber NUR int (im Backend und Ausgabe auf Website)

[zonky2]

ist die Frage, inwieweit MM "anhängig" vom Contao-Core-Timestamp-Feld ist? ich sehe erstmal keine Probleme, sich mit einem MM-Datumsattribut unabhängig vom Core zu machen...

siehe auch MetaModels/core#881 (comment)

[janmarkuslanger]

Gibt es hier zu schon etwas Neues oder eine Übergangslösung?

[zonky2]

leider nein :(

z.Z. alle Resourcen an MM 2.1 gebunden...

[discordier]

Is this the same as #9?

[zonky2]

ja/yes

[discordier]

Closing then.