Vous pourriez vouloir emprunter quelques idées à mon implémentation des dates de début/fin de bon dans la boîte de dialogue Nouveau bon dans un e-commerce sur lequel je travaille :
Un autre exemple pour démontrer la flexibilité et comment nous évitons l’ambiguïté dans les plages de dates dans l’interface utilisateur :
Détail technique : Dans notre application, nous enregistrons toujours les dates sous forme de « timestamp avec fuseau horaire » (postgres), de sorte qu’aucun paramètre de base de données, ni aucun paramètre de connexion, ne peut affecter le timestamp réel stocké. Même si Postgres ne le recommande pas, nous le faisons car cela garantit à 100 % la correction de la date dans toutes les situations et dans toutes les requêtes SQL. Vous pouvez manipuler les fuseaux horaires de date directement dans postgres en utilisant leurs fonctions de date/heure/fuseau horaire et être certain que cela fonctionnera toujours à 100 % correctement. Nous nous y fions.
Et ensuite, nous avons un paramètre de fuseau horaire pour tous les types d’entités qui en ont besoin : profils d’utilisateurs, marchés, bons, rapports pour les comptables, etc. - afin que nous puissions traduire n’importe quelles dates dans n’importe quels fuseaux horaires à la volée sans hésitation.
Les principaux points Ă retenir ici sont :
- Stockez toujours la date et l’heure avec le fuseau horaire.
- Stockez toujours la préférence du fuseau horaire.
- Soyez très explicite sur les dates dans l’interface utilisateur, ne faites pas de magie.
- Laissez l’utilisateur voir les dates réelles dans le fuseau horaire choisi avant de cliquer sur « Enregistrer ».