Re: datetime : passer d'« offset-naive » à « offset-aware »

Le 14/05/2023 22:10, Stefan Ram m'a répondu très justement :

 
  La documentation de "classe email.headerregistry.DateHeader"
  contient (traduit) :
 
|datetime
|Si la valeur de l'en-tête peut être reconnue comme une date
|valide d'une forme ou d'une autre, cet attribut contiendra une
|instance de datetime représentant cette date. Si le fuseau horaire
|de la date d'entrée est spécifié comme étant -0000 (ce qui indique
|qu'elle est en UTC mais ne contient aucune information sur le
|fuseau horaire de la source), datetime sera une datetime naïve.
|Si un décalage de fuseau horaire spécifique est trouvé (y compris
|+0000), datetime contiendra une datetime consciente qui utilise
|datetime.timezone pour enregistrer le décalage de fuseau horaire.
 
  (Un autre paragraphe similaire se trouve encore dans la documentation
  de "email.utils.parsedate_to_datetime" et des fonctions suivantes.)
 
  J'en déduis que "-0000" signifie que la date ne tient pas
  compte du fuseau horaire, tandis que "+0000" est une date qui
  tient compte du fuseau horaire, et que ces deux éléments ne
  peuvent pas être soustraits.

En effet, je viens tout juste de lire ceci dans le RFC 2822 :

   [...] The form "+0000" SHOULD be used to indicate a time zone at
   Universal Time.  Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and therefore
   indicates that the date-time contains no information about the local
   time zone.

Du coup, la plupart de mes correspondants étant en France, ce -0000 pourrait
tout aussi bien signifier +0000 que +0200.

Bah, dans ce cas ce sera tant pis si je ne peux pas comparer les dates avec
une absolue certitude, de toute façon ça dépend aussi de l'horloge sur la
machine de l'émetteur. L'essentiel est que mon programme ne plante pas.

--
Olivier Miakinen