Diese viel nachgefragte Funktion ermöglicht es Ihnen, anzugeben, wann eine Serie von wiederkehrenden Ereignissen enden soll, was Ihnen mehr Kontrolle über Ihre Terminplanung gibt.
Erstellen Sie tägliche, wöchentliche oder monatliche wiederkehrende Ereignisse – und legen Sie jetzt genau fest, wann sie enden sollen.
Eine knifflige Sache bei dem Wort „Bis“ ist, dass es nicht ganz offensichtlich ist, ob es eingeschlossen oder ausgeschlossen ist. Gibt es hier etwas, was wir tun können, um mehr Klarheit zu schaffen?
Eine alternative Lösung wäre, das tatsächliche Datum/die tatsächliche Uhrzeit neben der Datumseingabe anzuzeigen, aber wahrscheinlich übertrieben?
Sie könnten sich einige Ideen von meiner Implementierung der Gutschein-Start-/Enddaten im neuen Gutscheindialog in einem E-Commerce-System, an dem ich arbeite, abschauen:
Technische Details: In unserer Anwendung speichern wir Daten immer als „Timestamp mit Zeitzone“ (Postgres), sodass keine Datenbank- oder Verbindungseinstellung den tatsächlich gespeicherten Zeitstempel beeinflussen kann. Obwohl Postgres es nicht empfiehlt, tun wir es, weil es 100%ige Garantien für die Korrektheit des Datums in jeder Situation und jeder SQL-Abfrage bietet. Sie können mit Datum-Zeitzonen direkt in Postgres mit deren Datums-/Zeit-/Zeitzonenfunktionen arbeiten und sicher sein, dass dies immer zu 100% korrekt funktioniert. Wir verlassen uns darauf.
Und dann haben wir eine Zeitzoneneinstellung für alle Arten von Entitäten, die sie benötigen: Benutzerprofile, Märkte, Gutscheine, Berichte für Buchhalter usw. – damit wir beliebige Daten ohne zu zögern in beliebige Zeitzonen übersetzen können.
Die wichtigsten Erkenntnisse hier sind:
Speichern Sie Datum und Uhrzeit immer mit Zeitzone.
Speichern Sie immer die Zeitzonenpräferenz.
Seien Sie in der Benutzeroberfläche sehr explizit bei Daten, machen Sie keine Magie.
Lassen Sie den Benutzer die tatsächlichen Daten in der gewählten Zeitzone sehen, bevor er auf „Speichern“ klickt.
