Le moyen le plus propre et le plus pythonique d'obtenir le rendez-vous de demain?


120

Quelle est la manière la plus propre et la plus pythonique d'obtenir le rendez-vous de demain? Il doit y avoir un meilleur moyen que d'en ajouter un à la journée, de gérer les jours à la fin du mois, etc.

Réponses:


241

datetime.date.today() + datetime.timedelta(days=1) devrait faire l'affaire


39

timedelta peut gérer l'ajout de jours, secondes, microsecondes, millisecondes, minutes, heures ou semaines.

>>> import datetime
>>> today = datetime.date.today()
>>> today
datetime.date(2009, 10, 1)
>>> today + datetime.timedelta(days=1)
datetime.date(2009, 10, 2)
>>> datetime.date(2009,10,31) + datetime.timedelta(hours=24)
datetime.date(2009, 11, 1)

Comme demandé dans un commentaire, les jours bissextiles ne posent aucun problème:

>>> datetime.date(2004, 2, 28) + datetime.timedelta(days=1)
datetime.date(2004, 2, 29)
>>> datetime.date(2004, 2, 28) + datetime.timedelta(days=2)
datetime.date(2004, 3, 1)
>>> datetime.date(2005, 2, 28) + datetime.timedelta(days=1)
datetime.date(2005, 3, 1)

7

Pas de gestion des secondes intercalaires tho:

>>> from datetime import datetime, timedelta
>>> dt = datetime(2008,12,31,23,59,59)
>>> str(dt)
'2008-12-31 23:59:59'
>>> # leap second was added at the end of 2008, 
>>> # adding one second should create a datetime
>>> # of '2008-12-31 23:59:60'
>>> str(dt+timedelta(0,1))
'2009-01-01 00:00:00'
>>> str(dt+timedelta(0,2))
'2009-01-01 00:00:01'

Zut.

EDIT - @Mark: La documentation dit "oui", mais le code dit "pas tellement":

>>> time.strptime("2008-12-31 23:59:60","%Y-%m-%d %H:%M:%S")
(2008, 12, 31, 23, 59, 60, 2, 366, -1)
>>> time.mktime(time.strptime("2008-12-31 23:59:60","%Y-%m-%d %H:%M:%S"))
1230789600.0
>>> time.gmtime(time.mktime(time.strptime("2008-12-31 23:59:60","%Y-%m-%d %H:%M:%S")))
(2009, 1, 1, 6, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(time.strptime("2008-12-31 23:59:60","%Y-%m-%d %H:%M:%S")))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)

Je penserais que gmtime ou localtime prendrait la valeur renvoyée par mktime et me rendrait le tuple d'origine, avec 60 comme nombre de secondes. Et ce test montre que ces secondes intercalaires peuvent tout simplement disparaître ...

>>> a = time.mktime(time.strptime("2008-12-31 23:59:60","%Y-%m-%d %H:%M:%S"))
>>> b = time.mktime(time.strptime("2009-01-01 00:00:00","%Y-%m-%d %H:%M:%S"))
>>> a,b
(1230789600.0, 1230789600.0)
>>> b-a
0.0


C'est parce que l'heure Unix ne gère pas les secondes intercalaires. Voir en.wikipedia.org/wiki/Unix_time#History , mail-archive.com/leapsecs@rom.usno.navy.mil/msg00094.html et POSIX lui-même.

"chaque jour doit être compté exactement 86400 secondes" opengroup.org/onlinepubs/9699919799/basedefs

Les années bissextiles représentent la différence entre l'année solaire et 365 jours pairs, tandis que les secondes intercalaires sont intrinsèquement différentes et tiennent compte des différences causées par des facteurs externes comme les tremblements de terre. Cela les rend irréguliers et ne peut pas être déterminé de la même manière que, par exemple, déterminer le jour de la semaine où le 3 mars 2055 atterrira.
David Woods

1
@DavidWoods: les secondes intercalaires doivent maintenir UTC à +/- 0,9 seconde de UT1 (rotation de la Terre). Il y a 25 secondes intercalaires accumulées de 1972 à 2012. Les tremblements de terre sont trop faibles pour le provoquer ( un seul tremblement de terre peut introduire des changements de microseconde - mille fois moins qu'une différence de milliseconde typique dans la durée de la journée par rapport à 86400 secondes SI ).
jfs le

5

Même le timemodule de base peut gérer cela:

import time
time.localtime(time.time() + 24*3600)

1
Cela échoue aux limites de l'heure d'été aux États-Unis, car à ces limites, un jour aura 23 heures et un jour 25 heures. Cela ne prend pas non plus en compte les secondes intercalaires.
Charles Wood

@CharlesWood: cette réponse peut renvoyer une heure différente qui (dans certains fuseaux horaires) signifie qu'elle peut renvoyer une date différente (pas demain) mais elle renvoie toujours l'heure qui est exactement 24 heures à l'avance (la réponse acceptée renvoie minuit (heures inconnues à partir de maintenant) )). Je ne vois pas comment les secondes intercalaires peuvent changer le résultat ici à moins d'être appelées pendant une seconde intercalaire sur des systèmes où 23:59:60 et 00:00:00 ont le même horodatage.
jfs

Certes, ce sera toujours dans 24 heures, mais ce n'était pas la question. OP voulait savoir comment obtenir la date de demain . La chose des secondes intercalaires était juste pinailleuse;)
Charles Wood

@CharlesWood: oui. Je viens de préciser qu'il ne revient pas 23, 25 heures. Et oui, il peut renvoyer une mauvaise date (pas demain, par exemple, pour "2014-10-18 23:00:00" dans le fuseau horaire "Brésil / Est"). En relation: Compte tenu de l'heure UTC actuelle, comment déterminez-vous l'heure de début et de fin de la journée dans un fuseau horaire particulier? .
jfs

@JFSebastian Oui, j'essayais juste de souligner que les jours ne durent pas toujours 24 heures . Pas étonnant que travailler avec des dates soit si difficile; il est même difficile de communiquer à leur sujet: /
Charles Wood
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.