Moi, c'est pas le XML qui était tout pourri, c'était l'appli en face qui ne savait récupérer correctement... une date [[ISO 8601]] !
Explication : j'avais une appli en Java à faire évoluer. Elle devait parler à un Web-Service (développé en .Net, ça a son importance), via SOAP. Pour ce dernier, c'est la librairie Axis qui était utilisée.
Cette librairie génère des classes Java, en fonction d'un WSDL (et de XSD) donnés en entrée. Pour un champ "xsd:DateTime", elle utilise la classe Calendar de Java.
Lors de l'envoi des données, la date est générée au format ISO 8601, en utilisatn le fuseau 'Z' (heure UTC), après avoir appliqué correctement le décalage horaire heure française -> heure UTC.
Mais en face, c'est une classe DateTime de .Net, qui est utilisée ! Et cette dernière ne sait pas gérer les fuseaux : elle garde telle quelle la date (et l'heure) qu'on lui donne... et la stocke telle quelle ensuite en base de données !
"Facile : y a qu'à utiliser la classe Calendar de .Net, au lieu de la classe DateTime !"... Sauf que non ! D'autres applis utilisent déjà ce Web-Service, et fonctionnent toutes avec la classe "DateTime", donc le bug n'apparait pas. Et donc impossible de modifier le Web-Service, car effets de bord garantis...
Bref, il a fallu pourrir la seule appli qui fonctionnait correctement, en faisant la seule chose à ne pas faire : rajouter le décalage "heure française -> heure UTC" dans l'objet Calendar, avant de l'envoyer...
/me a honte !
# Problème inverse pour moi...
Posté par windu.2b . En réponse au journal Le cauchemard de l'ETL. Évalué à 2.
Explication : j'avais une appli en Java à faire évoluer. Elle devait parler à un Web-Service (développé en .Net, ça a son importance), via SOAP. Pour ce dernier, c'est la librairie Axis qui était utilisée.
Cette librairie génère des classes Java, en fonction d'un WSDL (et de XSD) donnés en entrée. Pour un champ "xsd:DateTime", elle utilise la classe Calendar de Java.
Lors de l'envoi des données, la date est générée au format ISO 8601, en utilisatn le fuseau 'Z' (heure UTC), après avoir appliqué correctement le décalage horaire heure française -> heure UTC.
Mais en face, c'est une classe DateTime de .Net, qui est utilisée ! Et cette dernière ne sait pas gérer les fuseaux : elle garde telle quelle la date (et l'heure) qu'on lui donne... et la stocke telle quelle ensuite en base de données !
"Facile : y a qu'à utiliser la classe Calendar de .Net, au lieu de la classe DateTime !"... Sauf que non ! D'autres applis utilisent déjà ce Web-Service, et fonctionnent toutes avec la classe "DateTime", donc le bug n'apparait pas. Et donc impossible de modifier le Web-Service, car effets de bord garantis...
Bref, il a fallu pourrir la seule appli qui fonctionnait correctement, en faisant la seule chose à ne pas faire : rajouter le décalage "heure française -> heure UTC" dans l'objet Calendar, avant de l'envoyer...
/me a honte !