Pour un système de planification, quelle est la meilleure façon de sauvegarder le fuseau horaire du client / événement dans une base de données centrale de serveur provenant de plusieurs sources mobiles, Web, application client. p>
J'ai besoin de la solution pour travailler avec toutes les bases de données dans les balises. P>
4 Réponses :
tout en UTC et une autre colonne pour le décalage. P>
Le décalage peut changer lorsque DST change, comment allez-vous quand vous devez changer le décalage?
Absolument la bonne réponse. Si vous n'utilisez pas un fuseau horaire spécifique pour baser tous vos horodatages, etc., vous allez avoir un monde de problèmes. Il suffit d'utiliser une table de recherche offset avec des plages de date, puis reliez votre utilisateur à cela. Ne stockez pas le décalage comme un nombre réel.
Le décalage est stocké selon E.G. est5edt code>.
Mais cela peut changer avec DST, par exemple je suis sur GMT + 2 code> en hiver et GMT + 3 code> en été
Cela vous fait eet2eedt code>. Ou quelle que soit la désignation.
J'utilise habituellement des noms de zone de ZoneInfo ( en.wikipedia.org/wiki/zoneinfo ) qui sont disponible dans la plupart du système que j'utilise (Java / PostgreSQL / UNIX) et qui ne change pas lorsque DST se produisent
Vérifiez convert_tz dans mysql. Vérifiez Steve G Répondre
PostgreSQL peut convertir le fuseau horaire à la volée: "Sélectionnez Timeestamp_utc_field au fuseau horaire 'America / Chicago'", par exemple, convertit les données dans le champ à la valeur appropriée, y compris les ajustements pour DST.
Store Dates comme TimeStamps UTC - Convertissez en temps local lors de l'affichage des données à l'utilisateur. P>
Ce sont les points clés de la stratégie que j'ai tendance à utiliser. P>
Notez que les réponses énumérées ci-dessous suggèrent toutes une approche pure-UTC, qui est pas i> idéal pour le cas des systèmes de planification. Voir la réponse acceptée en post DUP. Merci.