Path: ...!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!usenet-fr.net!.POSTED!not-for-mail
From: Olivier Miakinen <om+news@miakinen.net>
Newsgroups: fr.comp.lang.python
Subject: =?UTF-8?Q?Re:_datetime_:_passer_d'=c2=ab_offset-naive_=c2=bb_=c3=a0?=
 =?UTF-8?Q?_=c2=ab_offset-aware_=c2=bb?=
Date: Sun, 14 May 2023 22:20:07 +0200
Organization: There's no cabale
Lines: 42
Message-ID: <u3rfpo$29ek$1@cabale.usenet-fr.net>
References: <u3rcqv$28fu$1@cabale.usenet-fr.net>
 <u3reda$291m$1@cabale.usenet-fr.net>
 <-0000-20230514210908@ram.dialup.fu-berlin.de>
NNTP-Posting-Host: 200.89.28.93.rev.sfr.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: cabale.usenet-fr.net 1684095608 75220 93.28.89.200 (14 May 2023 20:20:08 GMT)
X-Complaints-To: abuse@usenet-fr.net
NNTP-Posting-Date: Sun, 14 May 2023 20:20:08 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.4
In-Reply-To: <-0000-20230514210908@ram.dialup.fu-berlin.de>
Bytes: 3098

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