asp.net datetime duplication aléatoire du décalage temporel. est un bug?

J'ai un site Web développé dans les serveurs asp.net 4 et sql 2008 R2. Le problème est très compliqué. J'ai un champ en db avec décalage de données UTC (par exemple 2015-09-30 18: 24: 53.1498113 +02: 00). Au hasard (je pense que lorsque le pool d'applications redémarre) cette valeur retourne corrompu après une requête dans .net comme ceci: 30/09/2015 18:21:00 +02: 00 +02: 00 Décalage de temps répété 2 fois! Donc, quand j'analyse la date dans C#, évidemment, je reçois une erreur "La chaîne n'a pas été reconnue comme un DateTime valide".asp.net datetime duplication aléatoire du décalage temporel. est un bug?

Si je recycle la piscine applcation la page travail bien

Pourquoi? C'est un bug? Avez-vous déjà vu un problème similaire?

Merci beaucoup

Source

2015-10-01 alex

On dirait que le collage de chaînes est en cours, mais vous ne nous avez pas donné suffisamment d'informations. – Ben

Salut Ben, il est très difficile de remplacer le problème car il arrive au hasard et seulement 3 fois en 6 mois que le site existe. – alex

Lorsque le pool d'applications redémarre (je pense) la date utc lue à partir de DB sont erronées. Le serveur Web dispose de paramètres de globalisation en italien, ainsi que du site Web dans web.config. Une seule fois en local, j'ai remplacé la situation. Et en utilisant Visual Studio Debug j'ai vu ce problème. La date dans l'ensemble de données était erronée (ex 09/09/2015 +02: 00 +02: 00). Je pense que c'est un bug parce que si je recycle le pool d'applications, le site fonctionne correctement ... – alex

-1

Le même problème est arrivé quand nous avons essayé d'analyser la chaîne convertie en utilisant la valeur DateTimeOffset.toString(). La conversion DateTimeOffset.toString() dans le client ADO.Net renvoie un format DateTimeOffset incorrect avec des valeurs de décalage en double. Nous avons arrêté la conversion de chaîne de DateTimeOffset et commencé à utiliser l'objet DateTimeOffset directement.

Source

2016-07-04 11:34:38

Vous aviez deux bogues - en utilisant le mauvais type pour stocker les valeurs DateTimeOffset et le mauvais code d'analyse. La seule solution logique dans ce cas consiste à modifier le type de la colonne à DateTimeOffset.PS 'ToString()' * formats *, il n'analyse rien et * n'est pas * cassé –

Dans Vertica DB, nous utilisons un type de colonne ([TIMESTAMPTZ] (https://my.vertica.com/ docs/7.1.x/HTML/index.htm # Authoring/SQLReferenceManual/DataTypes/Date-Heure/TIMESTAMPATTIMEZONE.htm)) Identique à DateTimeOffset pour stocker l'heure avec le décalage horaire. Nous avons essayé de convertir la valeur db récupérée en chaîne en utilisant la méthode ToString(). La valeur renvoyée de ToString() a été incohérente avec les valeurs Offset répétées de cette propriété. D'où la suspicion autour du client ADO.Net pour Vertica. Nous n'avons pas été en mesure de trouver quand cela se produisait, donc pas en mesure d'identifier exactement le problème. –

'DateTimeOffset.ToString()' ou 'String.Format' ne sont pas incohérents. Si le décalage apparaît deux fois, c'est parce que la chaîne de format contient deux fois le spécificateur de décalage. Il est facile de tester aussi - il suffit de créer une valeur DateOffset et d'utiliser la même chaîne de format –

Cela nous est arrivé aussi aujourd'hui - la première fois que je l'ai vu. Ce n'est certainement pas une erreur de la part d'Alex, c'est un DateTimeOffset fortement typé avec le standard de tourbillon .ToString() ajoutant le décalage deux fois. Cela ne se passe que sur l'un de nos serveurs Web, et je m'attends à ce qu'il disparaisse si nous le mettons en place. Je suis sûr que fournir explicitement un format de chaîne pour ToString l'empêcherait de se reproduire, et il est possible qu'il y ait une sorte de corruption au niveau du système, car j'ai vu les formats par défaut changer avec les mises à niveau du système. t se fixe quand on le frappe).

Source

2017-09-07 19:15:29

Nous avons observé le même comportement dans notre application asp.net-mvc (.NET 4.5) hébergée chez IIS. L'un des serveurs a commencé à générer des décalages dupliqués (aucune version ont été déployés pendant des semaines) lors de la sérialisation valeur DateTimeOffset du modèle cshtml de rasoir dans ce code apparemment inoffensif:

@Html.HiddenFor(m => m.CreateDate) 
<span>@Model.CreateDate</span>

Dans les deux endroits les décalages dupliqués ont été générés comme 2017-11 -20 12h34 +01: 00 +01: 00. Le redémarrage du pool IIS a résolu le problème, mais je ne sais pas comment l'éviter à l'avenir.

Source

2017-11-20 11:08:19 PanJanek

asp.net datetime duplication aléatoire du décalage temporel. est un bug?

Répondre

Questions connexes