Question

Pour autant que je sache, l'opérateur de différence du type DateTime considère les années bissextiles: donc

new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days

Mais qu'en est-il de l'heure d'été?

Était-ce utile?

La solution

Je ne pense pas que ce sera le cas. La documentation indique simplement qu'un DateTime est stocké comme le nombre de ticks depuis minuit, le 1er janvier 0001 à minuit, mais il n'est pas indiqué dans quel fuseau horaire minuit est réellement - je devrais supposer que s'il était toujours stocké de manière interne dans UTC, ils diraient oui.

Vous pouvez facilement contourner cela cependant: il suffit de faire:

var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime()

et les conversions en UTC prendront en compte l'heure d'été

Autres conseils

.NET ne gère pas correctement l'heure d'été, même s'il donne les réponses que vous souhaitez. Vous voulez des réponses incorrectes.

Version abrégée:

  • Comment .NET peut-il savoir qu’en 1977, l’heure était en vigueur toute l’année en raison de la crise énergétique?

  • Comment .NET peut-il savoir quelles seront les règles de l'heure d'été en Israël, alors que les règles sont décidées chaque année par la Knesset?

  • Comment .NET peut-il savoir que les États-Unis ont fonctionné à l'heure d'été pendant la Seconde Guerre mondiale, et qu'entre 1945 et 1966, les règles relatives à l'heure d'été variaient d'une région à l'autre, et les règles varient toujours d'une région à l'autre.

.NET tente une copie et utilise les règles de l'heure d'été en vigueur, même si elles n'étaient pas ou ne le seront pas. Le résultat est que vous obtenez des réponses qui, tout en étant ce que vous pensez vouloir, sont incorrectes.

Extrait de l'entrée de blog de Raymond Chen , Pourquoi l'heure avancée n'est-elle pas intuitive :

  

Pourquoi les fonctions de conversion de fuseau horaire (win32) n'utilisent-elles pas le fuseau horaire approprié pour la période de l'année?

     

...

     

Win32 n'essaie pas de deviner lequel   règles de fuseau horaire étaient en vigueur à cette   autre moment. Alors Win32 dit, " jeudi",   17 octobre 2002, 08:45:38 HNP ".

     

Remarque: Pacifique Standard Heure. Même   si 17 Octobre était au cours du Pacifique    Heure avancée , Win32 affiche l'heure.   comme heure normale parce que c'est ce que   il est temps maintenant .

     

.NET dit: " Eh bien, si les règles de   effet maintenant étaient également en vigueur sur   17 octobre 2003, alors ce serait   heure avancée du jour " donc il affiche   " Jeudi 17 octobre 2003 à 9h45.   PDT " - heure avancée du jour.

Donc, les réponses que vous obtenez sont fausses. Mais puisque vous attendez la mauvaise réponse, c'est ce que vous obtenez.

L'heure d'été est plus spécifique que les 12 fuseaux horaires généraux et les pays qui les ont utilisés.

Différents pays ou groupes de pays utilisent différentes dates pour déterminer l'heure d'été.

C'est un peu pénible de ne pas mentionner les pays qui ne le font pas, ou des parties de pays.

Par exemple, dans le Queensland, au Royaume-Uni, l’heure d’été est différente du reste du pays.

Je ne serais pas surpris que ce ne soit pas le cas, dans le cas contraire, il serait incapable de le faire avec un cultureinfo au moins).

Cela ne veut pas et cela NE PEUT ENCORE PAS , car cela ne vous oblige pas non plus à utiliser l'UTC pour construire un DateTime et ne vous permet pas non plus de spécifier si l'heure d'été était effective. lorsque vous construisez un DateTime avec une valeur d’heure locale. De plus, cela permet au mode (LT ou UTC) d’être "non spécifié", ce qui n’est que l’asine.

En autorisant la construction de valeurs DateTime à partir de valeurs Heure locale, il est possible de construire une valeur DateTime (spécifiée en tant qu'Heure locale) qui est ambiguë (par exemple à tout moment entre 1 et 2 heures le 2 novembre aux États-Unis, lorsque la heure se répète) et ne peut pas être reconverti de manière déterministe en UTC, SAUF SI le constructeur a fourni un paramètre permettant de spécifier si l'heure d'été était en vigueur pour l'heure locale donnée .

Comme il ne fournit aucun paramètre de ce type, la conception de la classe DateTime est incomplète et défectueuse, car elle n'a pas pris en compte tous les paramètres nécessaires pour spécifier correctement une heure locale.

Je pense que c'est la raison pour laquelle ils ont créé la classe DateTimeOffset, qui ... si vous avez du mal à comprendre pourquoi une classe aussi apparemment redondante existe ... voilà pourquoi.

En conséquence, vous ne devez jamais effectuer de calcul avec aucune instance DateTime qui ne soit pas définie sur DateTimeMode.Utc. Utilisez uniquement le temps UTC. En fait, vous ne pouvez pas convertir vers ou depuis LT, car deux bogues différents le font disparaître, dans les deux sens. 1. Passer de LT à UTC est interrompu parce que, comme mentionné, cela ne vous permet pas de spécifier si l'heure d'été était en vigueur pour cette heure ambiguë dans LT. Oh, cela vous permet également de spécifier une heure locale qui est pratiquement impossible, telle que l'heure que nous sautons lorsque les horloges sont programmées. 2. Lors de la conversion d'une valeur UTC dans le passé en une heure locale, Windows corrige cela en compensant pour l'heure d'été selon qu'elle est en vigueur MAINTENANT plutôt que l'heure donnée, qui est sérieusement asin. Bien sûr, vous avez peut-être remarqué ce problème lorsqu'une heure de modification que vous avez notée, stockée ou utilisée dans le nom d'un fichier apparaît un jour avec l'heure OFF dans l'explorateur Windows. Non, vous n'êtes pas fou, Windows contient un grave bogue, qu’ils n’ont jamais trouvé le temps de corriger quelque part entre la publication de DOS et le dernier framework .NET (~ 2 décennies)! Bien sûr, ce bogue affecte les systèmes CVS et tout ce qui suit les temps de modification. Le système de fichiers FAT stocke les heures sous forme d'heures locales, ce qui signifie qu'elles sont complètement foutues.

Testez-le et voyez!

Il est aussi facile de rédiger un test que pour le cas DST que pour le cas des années bissextiles.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top