Discussion :

[olibara]

Hello,

Guru needed !

Voici un tres intéressant problème de serialisation de date

J'ai une classe qui contient une date
Cette date est assignée a DateTime now sur un device mobile
Je transfere la classe a un web service

Si je transfere la classe directement apres assignation de la date, le web service reçoit une date décalée de 6 heure
Si par contre j'écris la date dans un fichier avec un bete tostring() et que ensuite je recrer une classe en relisant la date ecrite dans le fichier et que je la transfere au web service, elle aura la bonne valeur !!!

Une idée ??

Merci.

[PatteDePoule]

DateTime.Now semble prendre en compte le fuseau horaire. Je regarderais à ce niveau là.

[olibara]

Merci PatteDePoule

Oui je pense que tu a raison mais c'est quand meme vraiment strange
Car en résumé voici le constat

Test 1
1- J'assigne un Datetime a DateTime.Now; : 2011-03-30 17:15 PM
2- Je transfere ce datetime vers le serveur (donc serialisation automatique)
3- Le serveur reçois la date : 2011-03-30 23:15 PM

Test 2
1- J'assigne un Datetime a DateTime.Now; : 2011-03-30 17:15 PM
2- J'ecris datetime dans un fichier texte sw.WriteLine("{0}",MonDateTime);
3- Je controle le resultat : l'heure est bonne (je n'ai plus le format exact sous les yeux)
4- Je relis ce fichier : MonDateTime=DateTime.Parse(DateSauve);
5- Je transfere
6- la date recue est bonne

Donc il faut conclure que le mecanisme d'ecriture et de relecture modifie certains attributs du DateTime

Etant ern Belgique, cela signifie accessoirement que selon l'operation, le device peut se voir soit un GMT+1 soit en GMT+6

Une solution envisageable serait evidement de passer systematiquement par un preformatage en string du DateTime.now

Mais j'aimerais savoir s'il n'y a pas de solution plus robuste

[PatteDePoule]

Il faudrait peut-être que tu fonctionnes avec DateTime.UtcNow à la place?

[olibara]

Merci patte de poule

Je vais investiguer de ce coté

[Arthis]

Cela pourrait etre un probleme de culture du thread. Celui ci pourrait etre basé sur en-US par exemple et par la meme transformer ta date en UTC avec 6 heures de decalage pour atteindre l'utc.

[Bluedeep]

Cela pourrait etre un probleme de culture du thread. Celui ci pourrait etre basé sur en-US par exemple et par la meme transformer ta date en UTC avec 6 heures de decalage pour atteindre l'utc.

Non.
Le décalage horaire n'est pas une propriété de la cullture. On ne voit pas comment il pourrait l'être d'ailleurs, car cela supposerait une association culture-lieu géographique qui serait souvent dénuée de sens.

[Arthis]

autant pour moi. Merci du correctif.

Apres un peu de recherche il semblerait que ce ne soit pas culture comme je le pensais mais timezone qui est responsable de la gestion decalage horaire par rapport a l'UTC et que cette valeur serait liee a la machine pas au thread.

BlueDeep a entierement raison quant a utiliser seulement l'UTC. Beaucoup plus simple.

[Bluedeep]

Une solution envisageable serait evidement de passer systematiquement par un preformatage en string du DateTime.now

Je ne vois pas en quoi formatter en string le DateTime serait une solution.
Le mieux est de faire tout en UTC, puis ensuite d'afficher en fonction diu DateTimeOffset coté client et coté serveur. (la propriété OffSet du DateTimeOffset est un TimeSpan qui contient le décalage avec l'UTC).

[olibara]

Je ne vois pas en quoi formatter en string le DateTime serait une solution.

Ce que j'ai découvert rejois sans doute l'hypothese de Arthis

1- Le DateTime sur le device vaut 17h40
2- Ce dateTime transferé sur le serveur vaut 23h40
3- Par contre ce datetime passé par un string et ensuite par un DateTime.Parse et ensuite transféré au serveur vaut bien 17h40

Je soupconne donc que le DateTime.Now assigné a la base contienne une information de culture ou de localisation qui est utilisé dans la sérialisation WSDL
Par contre un DateTime.parse donne sans doute une valeur nulle de culture ou de localization et la sérialization utilise la valeur Verbatim (spéculation sur base du constat)

[Bluedeep]

Je soupconne donc que le DateTime.Now assigné a la base contienne une information de culture ou de localisation qui est utilisé dans la sérialisation WSDL
Par contre un DateTime.parse donne sans doute une valeur nulle de culture ou de localization et la sérialization utilise la valeur Verbatim (spéculation sur base du constat)

Tu devrais relire ma réponse et pas seulement la première ligne.

[Nathanael Marchand]

Il faut observer la propriété Kind du DateTime. Elle est soit Local, soit Utc, soit undefined.

Cf cet exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var a = DateTime.Now.Dump();
a.Kind.Dump();
a.ToUniversalTime().Dump();
a.ToLocalTime().Dump();
"---".Dump();
var b = DateTime.UtcNow.Dump();
b.Kind.Dump();
b.ToUniversalTime().Dump();
b.ToLocalTime().Dump();
"---".Dump();
var c = DateTime.Parse(DateTime.Now.ToString()).Dump();
c.Kind.Dump();
c.ToUniversalTime().Dump();
c.ToLocalTime().Dump();
"---".Dump();
var d = DateTime.Parse(DateTime.UtcNow.ToString()).Dump();
d.Kind.Dump();
d.ToUniversalTime().Dump();
d.ToLocalTime().Dump();

qui génére:

4/3/2012 2:39:30 PM
Local
4/3/2012 12:39:30 PM
4/3/2012 2:39:30 PM


4/3/2012 12:39:30 PM
Utc
4/3/2012 12:39:30 PM
4/3/2012 2:39:30 PM

4/3/2012 2:39:30 PM
Unspecified
4/3/2012 12:39:30 PM
4/3/2012 4:39:30 PM

4/3/2012 12:39:30 PM
Unspecified
4/3/2012 10:39:30 AM
4/3/2012 2:39:30 PM

[olibara]

Merci a tous

Bludeep : j'avais bien lu toutes tes lignes mais je repondais a ta question de la premiere ligne

Je ne vois pas en quoi formatter en string le DateTime serait une solution

Et ce que je soupconnait est clairement démontré par Nathanael : le DateTime.parse déspécifie le Kind et du coup ca permet indirectement de contourner le problème du du client et du serveur qui n'utilisent pas la meme reference

C'est pas joli j'en convient mais ca explique bien l'effet rencontré !
Merci et je marque résolu