2 votes

WCF to Entity Framework convertit ma date en heure locale - comment arrêter ?

J'ai un service WCF qui reçoit des enregistrements avec des valeurs de date et les enregistre dans une base de données Azure SQL, en utilisant Entity Framework 3.5, SP1. En l'exécutant localement, les enregistrements sont sauvegardés dans la base de données, tout va bien.

Cependant, mon hébergement IIS se trouve dans un autre fuseau horaire. Lorsque j'y télécharge le site et que j'appelle le même service (avec exactement la même chaîne de connexion, à la base de données Azure SQL), les enregistrements sont toujours sauvegardés, mais l'heure a reculé de 5 heures.

J'ai vérifié Fiddler, pour voir les données qui sortent, et c'est à mon heure locale. J'ai utilisé le même service dans le cadre d'un hébergement Azure, et cela a également fonctionné. J'ai sauvegardé les mêmes données vers un autre service WCF sur le même hôte avec Linq2SQL, et cela fonctionne bien.

La seule différence est alors Entity Framework - je suppose que mon information sur le fuseau horaire (GMT) est envoyée avec la date, et que lorsque le serveur reçoit l'heure de la côte Est, il la convertit à l'heure locale, 5 heures plus tôt.

D'une certaine manière, c'est exact, car à l'heure actuelle (13:48), il est 5 heures plus tôt - 08:48, mais ce n'est pas ce que je veux qu'il enregistre dans la base de données, je veux qu'il enregistre 13:48. Je veux qu'il enregistre 13:48, comme je l'ai demandé, pour que cela ait un sens lorsque je l'interroge.

C'est probablement très simple, et tout le monde connaît la réponse, mais je suis un peu perplexe. J'apprécierais vraiment que quelqu'un m'oriente dans la bonne direction.

de nombreux remerciements

Toby

2voto

Martin Harris Points 18057

Vous pouvez essayer de changer le DateTimeKind sur la valeur côté client en Unspecified. De cette façon, WCF et Entity Framework n'auront pas assez d'informations pour essayer de la convertir intelligemment.

DateTime.SpecifyKind
DateTimeKind


Pour faire suite à ce dysfonctionnement et à votre commentaire dans la question...

Premièrement, qu'essayez-vous de faire ? Voulez-vous que les valeurs stockées dans la base de données soient dans le fuseau horaire du client - dans votre cas, l'heure britannique - ou voulez-vous qu'elles soient stockées en UTC ? D'après mon expérience, la meilleure solution est d'enregistrer les données en UTC, sinon vous risquez de vousmer la confusion si vous avez plusieurs clients dans des fuseaux horaires différents.

En supposant que vous souhaitiez le stocker en UTC, vous devez le convertir en UTC du côté du client avant de le transmettre sur le réseau ( DateTime.ToUniversalTime ), vous devez alors vous assurer que le serveur le reconnaît comme UTC (il devrait le faire automatiquement, mais vous pouvez appeler SpecifyKind après l'avoir reçu, juste pour être sûr). Le cadre d'entités devrait puis le stocker dans la base de données sans modification - comme vous le décrivez dans votre commentaire.

L'astuce consiste à se rendre compte que l'heure à laquelle vous retrouvez le client lorsque vous récupérez les données sera en UTC. Par conséquent, si l'heure britannique ne correspond plus à l'heure UTC, elle apparaîtra comme erronée. Veillez donc à appeler DateTime.ToLocalTime sur toutes les valeurs renvoyées par le serveur avant de les afficher à l'utilisateur.

C'est du moins l'approche adoptée I serait nécessaire.

(Oh, et en tant que développeur britannique, je trouve qu'il est très utile de régler l'heure de mon PC client sur une autre heure que l'heure britannique lorsque je fais ce genre de travail - sinon, vous introduirez des bogues que vous ne détecterez que lorsque nous passerons à l'heure d'été. D'après mon expérience, cela a tendance à se produire après le passage à l'heure normale.)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X