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:
Ein weiteres Beispiel, um die Flexibilität zu demonstrieren und wie wir Mehrdeutigkeiten bei Datumsbereichen in der Benutzeroberfläche vermeiden:
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.