Malheureusement, il n'y a pas de solution miracle. L'internationalisation d'une application devrait faire partie des toutes premières discussions de conception, car elle se situe au cœur de nombreux domaines, y compris les comparaisons date / heure et le formatage de la sortie.
Quoi qu'il en soit, pour suivre la voie de Doing It Right, il est essentiel de stocker les informations de fuseau horaire avec l'heure . En d’autres termes, réaliser que la date / heure 20130407 14:50
n’a pas de sens sans (a) y compris le décalage UTC actuel du fuseau horaire (note 1) , ou le plus probable 0). Sans l'une de ces choses, deux valeurs temporelles données sont incomparables et les données sont corrompues . (Cette dernière méthode consiste à jouer avec le feu (note 2) , d'ailleurs; ne le faites pas.)
Dans SQL Server 2008+, vous pouvez stocker le décalage avec l'heure directement à l'aide du datetimeoffset
type de données. (Pour être complet, en 2005 et avant, j’ajouterais une deuxième colonne pour stocker la valeur de décalage UTC actuelle (en minutes).)
Cela facilite la tâche des applications de type bureau, car ces plates-formes disposent généralement de mécanismes permettant de convertir automatiquement une date / heure + un fuseau horaire en heure locale, puis de les formater en sortie, le tout en fonction des paramètres régionaux de l'utilisateur.
Pour le Web, qui est une architecture intrinsèquement déconnectée, même si les données principales sont correctement configurées, la tâche est plus complexe, car vous avez besoin d'informations sur le client pour pouvoir effectuer la conversion et / ou le formatage. Cela se fait généralement via les paramètres de préférences utilisateur (l’application convertit / formate les éléments avant la sortie) ou simplement en affichant des éléments avec le même format fixe et le même décalage de fuseau horaire pour tous (comme le fait actuellement la plate-forme Stack Exchange).
Vous pouvez voir comment, si les données back-end ne sont pas configurées correctement, très rapidement, cela va devenir compliqué et hacky. Je ne recommanderais pas de suivre l'une de ces voies, car vous vous retrouverez avec plus de problèmes par la suite.
Note 1:
Le décalage UTC d'un fuseau horaire n'est pas fixe: prenez en compte l'heure d'été lorsque le décalage UTC d'une zone varie de plus ou moins une heure. De plus, les dates d'heure d'été des zones varient régulièrement. Donc, utiliser datetimeoffset
(ou un composé de local time
et UTC offset at that time
) résulte en une récupération maximale de l'information.
Note 2:
Il s'agit de contrôler les entrées de données. Bien qu'il n'existe aucun moyen infaillible de valider les valeurs entrantes, il est préférable d'appliquer une norme simple qui ne nécessite pas de calculs. Si une API publique s'attend à un type de données comprenant un décalage, cette exigence sera claire pour l'appelant.
Si ce n’était pas le cas, l’appelant doit s’appuyer sur la documentation (s’il la lit), ou le calcul est mal effectué, etc. ou même simplement Web / base de données sur des serveurs distincts, comme dans le cas présent).
Stocker le décalage tue quand même deux oiseaux avec une pierre; et même si cela n'est pas nécessaire maintenant , la possibilité est disponible ultérieurement si nécessaire. Certes, cela prend plus de mémoire, mais je pense que cela vaut la peine, car les données sont perdues si elles ne sont jamais enregistrées.