Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.lang.python > #4057 > unrolled thread

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

Back to article view | Back to fr.comp.lang.python

Contents

  datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2023-05-14 21:29 +0200
    Re: datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2023-05-14 21:56 +0200
      Re: datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2023-05-14 22:20 +0200
        Re: datetime : passer d'« offset-naive » à « offset-aware » Thierry Pinelli <festiventu+news@gmail.com> - 2023-05-15 10:36 +0200
          Re: datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2023-05-15 15:33 +0200
            Re: datetime : passer d'« offset-naive » à « offset-aware » "pata...@gmail.com" <patatetom@gmail.com> - 2023-05-25 06:48 -0700
              Re: datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2023-05-25 17:31 +0200
                Re: datetime : passer d'« offset-naive » à « offset-aware » Jo Engo <yl@icite.fr> - 2024-12-28 17:16 +0000
                  Re: datetime : passer d'« offset-naive » à « offset-aware » Olivier Miakinen <om+news@miakinen.net> - 2024-12-28 21:13 +0100

#4057 — datetime : passer d'« offset-naive » à « offset-aware »

Bonjour,

Je voudrais pouvoir comparer en python des dates de courriels, au format défini
par le RFC2822. Pour cela, j'utilise la fonction parsedate_to_datetime() qui est
définie dans le module email.utils :

from email.utils import parsedate_to_datetime
date = parsedate_to_datetime("Sat, 13 May 2023 12:00:00 +0200")


Tout fonctionne très bien, y compris lorsque le timezone est +0000. Mais lorsque
c'est -0000 le datetime correspondant se retrouve sans aucun tzinfo :

date1 = parsedate_to_datetime("Sat, 13 May 2023 12:00:00 +0000")
-> datetime.datetime(2023, 5, 13, 12, 0, tzinfo=datetime.timezone.utc)

date2 = parsedate_to_datetime("Sat, 13 May 2023 12:00:00 -0000")
-> datetime.datetime(2023, 5, 13, 12, 0)


Le problème est qu'alors python refuse de faire la différence entre ce datetime
sans tzinfo et ceux qui en ont un :

date1 - date2
-> TypeError: can't subtract offset-naive and offset-aware datetimes


D'où ma question : comment détecter qu'un datetime n'a pas de tzinfo, et dans
ce cas seulement lui coller le tzinfo=datetime.timezone.utc ? Ou bien, autre
solution, est-ce que je peux remplacer parsedate_to_datetime() par une fonction
qui définirait bien le tzinfo dans tous les cas ?

-- 
Olivier Miakinen

[toc] | [next] | [standalone]

#4058

Re-bonjour,

Le 14/05/2023 21:29, Olivier Miakinen a écrit :
> 
> Je voudrais pouvoir comparer en python des dates de courriels, au format défini
> par le RFC2822. Pour cela, j'utilise la fonction parsedate_to_datetime() qui est
> définie dans le module email.utils :
> 
> from email.utils import parsedate_to_datetime
> date = parsedate_to_datetime("Sat, 13 May 2023 12:00:00 +0200")
> 
> [...] comment détecter qu'un datetime n'a pas de tzinfo, et dans
> ce cas seulement lui coller le tzinfo=datetime.timezone.utc ? Ou bien, autre
> solution, est-ce que je peux remplacer parsedate_to_datetime() par une fonction
> qui définirait bien le tzinfo dans tous les cas ?

Bon, RTFM comme on dit, j'ai lu le manuel et j'arrive à ça :

===============================================================
from email.utils import parsedate_to_datetime
from datetime import datetime, timezone

def my_parsedate(rfc2822_date):
    d = parsedate_to_datetime(rfc2822_date)
    if (d.tzinfo is None) or (d.tzinfo.utcoffset(d) is None):
        # d is a naive timedate, make it aware
        d = datetime.combine(d.date(), d.time(), timezone.utc)
    return d
===============================================================

Est-ce que ça vous semble correct ? Et si même ça l'est, y aurait-il mieux ?


Cordialement,
-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#4060

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

[toc] | [prev] | [next] | [standalone]

#4061

Le 14/05/2023 Olivier Miakinen <om+news@miakinen.net> écrivait  :


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

devenu 5322

[toc] | [prev] | [next] | [standalone]

#4062

Le 15/05/2023 10:36, Thierry Pinelli m'a répondu :
> 
>> En effet, je viens tout juste de lire ceci dans le RFC 2822 :
> 
> devenu 5322

Tu as tout à fait raison. Cela dit, et je viens de le vérifier, il n'y a pas
eu de modification concernant le format de la date (et en particulier le
timezone), contrairement à ce qui s'est passé entre les RFC 822 et 2822.

-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#4063

Le lundi 15 mai 2023 à 15:35:12 UTC+2, Olivier Miakinen a écrit :
> Le 15/05/2023 10:36, Thierry Pinelli m'a répondu :
> > 
> >> En effet, je viens tout juste de lire ceci dans le RFC 2822 : 
> > 
> > devenu 5322
> Tu as tout à fait raison. Cela dit, et je viens de le vérifier, il n'y a pas 
> eu de modification concernant le format de la date (et en particulier le 
> timezone), contrairement à ce qui s'est passé entre les RFC 822 et 2822. 
> 
> -- 
> Olivier Miakinen

très bonne doc sur la problématique posée :
https://www.docstring.fr/blog/la-gestion-des-dates-avec-python/
si ça peut aider...

[toc] | [prev] | [next] | [standalone]

#4065

Bonjour,

Le 25/05/2023 15:48, pata...@gmail.com a écrit :
> 
> très bonne doc sur la problématique posée :
> https://www.docstring.fr/blog/la-gestion-des-dates-avec-python/
> si ça peut aider...

Ah oui, cette page semble très bien, mais c'est un peu difficile à lire avec
le texte en gris sur fond bleu foncé. Heureusement ça redevient lisible si on
désactive les CSS.

Je vais la lire dès que j'aurai 28 minutes devant moi... ;-)

-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#4275

Le Thu, 25 May 2023 17:31:28 +0200, Olivier Miakinen a écrit :

>> https://www.docstring.fr/blog/la-gestion-des-dates-avec-python/
>> si ça peut aider...
> 
> Ah oui, cette page semble très bien, mais c'est un peu difficile à lire
> avec le texte en gris sur fond bleu foncé.

Le webmaster a dû t'entendre, ou alors c'est juste le mode nocturne qui 
est plus lisible. Retourne-voir :)



-- 
Et relate leur ce gazage cruel, et ... alerte !
		-- Schmitter, Frédéric

[toc] | [prev] | [next] | [standalone]

#4276

Le 28/12/2024 à 18:16, Jo Engo a écrit :
> Le Thu, 25 May 2023 17:31:28 +0200, Olivier Miakinen a écrit :
          ^^^^^^^^^^^
> 
>>> https://www.docstring.fr/blog/la-gestion-des-dates-avec-python/
>>> si ça peut aider...
>> 
>> Ah oui, cette page semble très bien, mais c'est un peu difficile à lire
>> avec le texte en gris sur fond bleu foncé.
> 
> Le webmaster a dû t'entendre, ou alors c'est juste le mode nocturne qui 
> est plus lisible. Retourne-voir :)

En plus d'un an et demi, il y a des chances que je n'aie pas été le seul
à lui parler de la difficulté de lire du gris sur bleu foncé. Ou alors
rien n'a changé sur le site, et cela dépend du navigateur. En mai 2023
j'étais probablement chez moi avec SeaMonkey et Firefox sur Linux, alors
que là je teste avec SeaMonkey et Edge sur Windows. Dans ce SeaMonkey le
texte est en noir sur fond gris clair, alors qu'avec Edge il est en gris
clair sur fond noir.

-- 
Olivier Miakinen

[toc] | [prev] | [standalone]

Back to top | Article view | fr.comp.lang.python

csiph-web