Problème de conversion d'une date locale en date utc

Bonjour à tous

Dans un logiciel de préparation de base, je dois intégrer des données représentant des rendez-vous sur un agenda. Les données à intégrer sont dans un fichier texte format délimité (une variante du csv, en gros). Pour simplifier les traitements les données sont d'abords intégrées en l'état dans des tables temporaires via la commande BulkCopy de .net, ou, accessoirement en utilisant open bulk dans une requête.

Ma date est une date locale française usuelle, donc en heure d'hiver ou d'été suivant le jour. Dans le fichier elle est sous la forme JJ/MM/YYYY ou JJ/MM/YYYY hh:mm. Elle est intégrée en l'état dans la table temporaire, dans une colonne Datetime. Jusque là pas de problème.

Je dois mettre cette date dans la table du logiciel destination, colonne de type Datetime aussi, sauf que le logiciel attend une date UTC.
Je pensais que je devais utiliser GETDATEUTC pour faire la conversion, mais je me rend compte que, si mes rendez-vous sur des périodes hivernales sont corrects, ceux sur une période estivale se retrouvent décalés, +1h.

GETDATEUTC n'est visiblement pas la solution.

Comment faire cette conversion ?


EDIt : J'ai oublié de préciser : SQL2008 R2 PRO et éventuellement Express.


EDIT 2 : le décalage est logique, j'utilise la formule suivante pour calculer la date à enregistrer

Code:

---

DATEADD(second,DATEDIFF(second, GETDATE(), GETUTCDATE()),dbo._ImportCalendrier.[DateDebut]) ,

---

. Et donc le décalage se calcule effectivement par rapport au décalage actuel et non pas par rapport au décalage correspondant à la date à convertir. Je ne sais donc pas comment faire puisque toutes mes recherches me renvoie vers GetUTCDate.

Il n'y a aucune possibilité de récupérer correctement de l'heure localisée en heure universelle. Pourquoi ? Simplement parce que au moment du changement d'heure tu peut te retrouver avec deux valeurs identiques de DATETIME malgré que ce soit deux événements différents dans le temps.

Explication :
Le passage à l'heure d'été se fait en retardant d'une heure les horloges. A 3h du matin, l'horloge repasse à 2h.
Imaginons le scénario suivant :
1) un événement a lieu 15 minutes après 1h55 du matin. Le temps capturé à ce moment est de 2h10
2) un événement a lieu 75 minutes après 1h55 du matin. Le temps capturé à ce moment est de 2h10 parce que à 3h, l'heure est revenue à 2h...

Lequel de ces deux événements était à l'heure d'hiver ? ou à l'heure d'été ?

Impossible de le savoir.

C'est pourquoi depuis toujours j'impose à mes clients de travailler en heure UTC directement ou bien en heure localisée avec fuseau.

A +

Ouais, c'est quand même pas une incertitude sur une fourchette d'une heure par an qui va empêcher de faire qq chose.
Déjà, ça dépend si c'est de le résultat peut souffrir de cette incertitude et s'il y a une activité pendant cette période...

Perso, pour faire un truc rapidement crado, je ferai une fonction qui ajusterait la valeur d'entré en fonction des fourchettes des heures d'été / hiver.
Si tu n'as pas beaucoup d'années, ça devrait être simple.

Citation:

---

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Déjà, ça dépend si c'est de le résultat peut souffrir de cette incertitude

---

Théoriquement pas vraiment, mais, sachant que ce sont des rendez-vous professionnels sur un agenda, français, à priori pour au moins 99% des cas, et si l'incertitude se produit uniquement aux heures de basculement, il est probable qu'il y ait peu de rendez-vous nocturnes justement les jours de basculement, qui seraient impactés.

Il semblerait que, en script sql, pour les version SQL Server avant la 2016, il n'y ait pas de solutions directes possibles. A partir de la version 2016, il a de nouvelles fonctions, AT TimeZone notamment, qui pourraient peut-être convenir, et encore, j'en suis pas convaincu.

A force de consulter divers forums, j'ai réussi à mettre en place quelque chose, mais il faut, maintenant que je teste bien.
Je suis parti sur le principe d'une table annexe "timezone" dans laquelle je calcule et stocke la période qui correspond à l'heure d'été pour chacune des années et d'une fonction sql qui me convertie la date sur le principe que, si ma date est dans une des périodes de ma table "timezone", j'enlève 2h, sinon j'enlève 1h.

C'est pas forcément très joli, mais çà semble marcher sur mon poste (os français configuré en français, sqlserver français configuré en français) mais il faut que je teste plus précisément.

Les inconvénients (qui n'en sont pas forcément dans mon cas) sont que je me suis limité à la règle française de basculement, que je ne peux pas convertir n'importe quelle date mais uniquement celles dans la fourchette de calcul des périodes d'été (j'ai pris 2000/2050, je pense que c'est suffisant dans mon cas), que, si la règle change pour les années à venir, il faudra revoir ça....

Il faudra que je regarde aussi avec une localisation différente de l'os/sqlserver, car la collègue qui m'a remonté le problème n'avait pas 1 mais 2h de décalage de ce que j'ai compris, Je la soupçonne de ne pas avoir installer les mêmes versions que tout le monde.

Citation:

---

Envoyé par sevyc64

Il faudra que je regarde aussi avec une localisation différente de l'os/sqlserver, car la collègue qui m'a remonté le problème n'avait pas 1 mais 2h de décalage de ce que j'ai compris, Je la soupçonne de ne pas avoir installer les mêmes versions que tout le monde.

---

Pour info dans les bases internationales la conversion UTC vers local (ou l'inverse) est complexe et dépend de deux paramètres :
du fuseau horaire (les USA ou le russie en ayant plusieurs)
des passages de l'heure d'été et l'hiver et vice versa

Sans collecte du fuseau de l'horaire local c'est donc déjà impossible
Et en sus certains pays ont une règle de date des passages hiver/été ou vice versa fluctuante (exemple le Brésil, qui prends un arrêté de modification de la date lorsque la date théorique est trop proche de carnaval !).

Il faut donc une table croisant les pays et les fuseaux avec pour chaque pays la règle adoptée.....

Bon courage.

J'ai implémenté cela pour la première fois chez Alstom pour une base de maintenance mondiale il y a 10 ans....
Et comme déjà dit, je ne stocke que de l'UTC, jamais du local.

Mais tu peut choisir de stocker les deux (UTC et local) notamment si tu es en C/S avec client lourd.

A +

Citation:

---

Envoyé par SQLpro

Pour info dans les bases internationales la conversion UTC vers local (ou l'inverse) est complexe et dépend de deux paramètres :
du fuseau horaire (les USA ou le russie en ayant plusieurs) des passages de l'heure d'été et l'hiver et vice versa

---

Oh oui, pour le Canada, il y a une poignée de fuseaux différents et la logique est illogique au possible : ce n'est pas nécessairement délimité par province, à peine par région... Et entre la Saskatchewan qui ne change pas d'heure et Terre-Neuve qui est à UTC-3:30 (ou -2:30 en été), c'est un joyeux bordel.
Et en plus, la date du changement d'heure a été décalée d'une semaine par rapport à l'Europe, il y a une dizaine d'année, pour suivre le voisin du Sud...

Chez un ancien employeur, ils avaient essayé d'implanter ça suivant la ville mais ils avaient rapidement arrêté les frais...

Cependant, j'ai pris comme postulat que sevyc64 fait affaire avec un seul pays, est-ce que me trompe-je ?

Citation:

---

Envoyé par SQLpro

Et comme déjà dit, je ne stocke que de l'UTC, jamais du local.

---

Ce n'est pas ici un problème de stockage mais un problème de migration de données, donc des données à traduire pour les faire digérer à notre nouveau logiciel. Ces données peuvent venir de nos vieux (très vieux pour certains) logiciels, mais aussi de logiciels concurrents.

Citation:

---

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Cependant, j'ai pris comme postulat que sevyc64 fait affaire avec un seul pays, est-ce que me trompe-je ?

---

Pour l'instant, à ma connaissance, oui.

Mais tout ça va peut-être être remis en cause.
J'ai finalisé la version ce matin et fait les derniers tests, tout me semble correct, la version est livrable depuis midi.
Mais les têtes pensantes s'en sont mêlées et pense qu'il faudrait peut-être faire plutôt supporter l'effort du calcul, en amont, à l'export des données et non pas au moment du traitement de récupération.
Bref, c'est que le boulot est fait que l'on pense à réfléchir à quoi mettre dans le cahier des charges.

Sachant au passage que la semaine dernières quelques dents ont grincé parce que je retardais la sortie de cette version à cause de ce problème à corriger avant :marteau:

Citation:

---

Envoyé par sevyc64

Bref, c'est que le boulot est fait que l'on pense à réfléchir à quoi mettre dans le cahier des charges.

---

:ptdr: