Discussion :

[L'AMI Yves]

Mes problèmes de MySQL sont résolus depuis pas mal de temps : j'avance (comme un "pieds-lourds" !) et je me trouve maintenant confronté à une problème qui m'agace, mais qui m'agace ...!

Voici : je lis dans ma base de données une enregistrement qui contient une date et une heure, et mon problème est de savoir si cette date est aujourd'hui, et si, dans ce cas, l'heure est passée.

Les informations qui viennent de la base de données sont dans une table, fournie par "fetchall"). la case de la table pour la date affiche "datetime(2024, 1, 25)" et la case pour l'heure : "datetime.timedelta(seconds=22500)".

Pour faire ma comparaison, il faudrait que j'exprime l'heure actuelle, qui doit s'obtenir plus ou moins par "datetime.time.timedelta...". Je n'y arrive pas.

Merci de votre aide.

AMIcalement.

[wiztricks]

Pour faire ma comparaison, il faudrait que j'exprime l'heure actuelle, qui doit s'obtenir plus ou moins par "datetime.time.timedelta...". Je n'y arrive pas.

Si on part de:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> import datetime as dt
>>> d1 = dt.datetime(2024, 1, 25)
>>> dd = dt.timedelta(seconds=22500)

on peut fabriquer une date et heure via:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> d1 + dd
datetime.datetime(2024, 1, 25, 6, 15)

que l'on peut comparer à "maintenant":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> d1 + dd < dt.datetime.now()
True
>>>

- W

[umfred]

tu as regardé la doc de timedelta? https://docs.python.org/fr/3/library...edelta-objects
on y voit qu'il y a des paramètres nommés pour son initialisation, donc ça se résume bêtement en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
n=datetime.now()
td=timedelta(hours=n.hour, minutes=n.minute, seconds=n.second)

[Sve@r]

Bonjour

Voici : je lis dans ma base de données une enregistrement qui contient une date et une heure, et mon problème est de savoir si cette date est aujourd'hui, et si, dans ce cas, l'heure est passée.

Euh... tu sais que SQL possède des outils de check dates permettant par exemple de demander directement dans ta requête SQL, style select data from table where info < now() plutôt que le faire faire par Python...
Python c'est bien, non pas parce qu'il fait les choses tout seul mais surtout parce qu'il collabore avec le reste...

[L'AMI Yves]

Merci à tous. J'apprends, alors ça coince souvent, et ça n'avance pas vite.

J'essaie de remplacer une appli que j'avais écrite "jadis" en VB6, qui affichait mes rendez-vous comme des "post-it", et qui sonnait quand l"heure approchait. Malheureusement, à l'occasion d'une mise à jour de Windows 10, elle a cessé de fonctionner.

Mais l'idée de sélectionner les enregistrements dans la base de données suivant "hier", "aujourd'hui avant l'heure", "aujourd'hui après l'heure", "demain" ne m'est tout simplement pas venue, et ne me paraît pas tellement à propos dans mon projet.

Personne ne m'a suggéré d'exprimer "Now" sous forme d'un nombre de secondes depuis minuit : c'est une option qui n'existe pas dans "datetime" ? Mais alors, pourquoi mysql.connector le fait-il ?

J'étudie les réponses de près, et je reviens.

AMIcalement.

[wiztricks]

Personne ne m'a suggéré d'exprimer "Now" sous forme d'un nombre de secondes depuis minuit : c'est une option qui n'existe pas dans "datetime" ?

Un nombre de secondes depuis minuit est une durée pas une date.

Les opérations qu'on peut faire sur ces objets ne sont pas identiques: on sait ajouter des durées, ajouter des durées à des dates (qui donne une date) mais pas ajouter 2 dates (mais soustraire 2 dates donnera une durée).

Vous devez faire la différence entre une représentation interne "pratique" pour faire faire des calculs par l'ordinateur et le rendu (ce que verra) l’utilisateur.
Par exemple:
une date/heure:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> dt.datetime.now()
datetime.datetime(2024, 3, 15, 14, 39, 35, 415674)
>>>

on peut en extraire heures, minutes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> print(_.hour, _.minute)
14 39
>>>

sans passer par un timedelta.

- W

[L'AMI Yves]

Cher Wiztricks ! Tu me parles comme à un enfant. Bon, c'est vrai que je suis comme un enfant en Python, mais il ne faut pas exagérer.

Puisque j'exprime un instant dans ma base de données (même si c'est un instant à l'intérieur d'un jour, et non pas un instant dans le temps universel), je ne suis pas particulièrement surpris que mysql.connector exprime cet "instant" en durée depuis minuit (ce qui ne représente pas non plus un instant dans le temps universel), mais, vu le nombre invraisemblable de sous-fonctions qu'il y a dans les modules "time" et "timedata", je n'en reviens pas qu'il n'y en ait pas une pour exprimer "l'heure qu'il est à cet instant", que ce soit en nombre de secondes ou en heure-minute-secondes, comme nous appréhendons tous ce concept en regardant notre montre.

Mais c'est pas grave, je vais ajouter une ligne de code, on n'est pas à ça près.

AMIcalement.

[wiztricks]

je n'en reviens pas qu'il n'y en ait pas une pour exprimer "l'heure qu'il est à cet instant", que ce soit en nombre de secondes ou en heure-minute-secondes. comme nous appréhendons tous ce concept en regardant notre montre.

C'est pourtant ce que fait le petit exemple que je vous ai montré.

je ne suis pas particulièrement surpris que mysql.connector exprime cet "instant" en durée depuis minuit

Ca dépend surtout du type (de la colonne MYSQL choisi par vous) qui doit être un TIME et non un DATETIME... Le mysql.connector là dedans ne fait que traduire le type MYSQL en type Python.

- W

[papajoker]

bonjour

comme il a été dit plus haut, normalement tu fais ce traitement en sql
reste à savoir quel format tu utilises dans ta BD

existe des fonctions avec mysql comme timediff et datediff qui peuvent donc te retourner une liste en fonction du delta que tu désires

select * where HOUR( TIMEDIFF(NOW(), ma_date_time) ) > 9
select *, HOUR( TIMEDIFF(NOW(), ma_date_time) ) as difference ... order by difference /* where difference < 24

edit: à la place de la fonction NOW(), on peut passer une chaine venant d'une fonction python datetime

[Sve@r]

...mais, vu le nombre invraisemblable de sous-fonctions qu'il y a dans les modules "time" et "timedata", je n'en reviens pas qu'il n'y en ait pas une pour exprimer "l'heure qu'il est à cet instant", que ce soit en nombre de secondes ou en heure-minute-secondes

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
from datetime import datetime
print datetime.now()

comme nous appréhendons tous ce concept en regardant notre montre.

On fait ça machinalement mais derrière ce concept, il y a un tas d'opérations implicites de notre intellect. Et ces opérations, pour un ordinateur, doivent être alors explicitées. Et ensuite lui décrire le temps qui passe (après 01:59:59 ça passe à 02:00:00) ou le décalage (combien de temps entre 12:25:17 et 13:11:55)... bref ce n'est pas parce que ça nous semble simple que ça l'est réellement.

Pour la petite histoire, le temps Unix (Windows je ne sais pas) est exprimé en secondes depuis sa naissance (01/01/1970). Ainsi les calculs en sont simplifiés et la conversion "humaine" ne se fait que lors de l'affichage ou de la saisie.

[umfred]

ça dépend plus du type de la colonne de ta base de données.
Le type TIME représente une heure, mais pas une heure de la journée (en cela, qu'elle va de -838:59:59 à 838:59:59)

[L'AMI Yves]

Je vois bien que ce sont des experts qui s'expriment ici, et que de toutes façons, hors les experts, point de salut. mais permettez-moi, juste le temps de le dire, d'exprimer le point de vue d'un "intuitionniste" : je veux faire une application de gestion de rendez-vous. hors les questions de personne de motif et de lieu, un rendez-vous est caractérisé par une date et une heure. Il y a donc dans ma base de données des rendez-vous avec des dates et des lieux. Et, pour un humain, l caractéristique d'un rendez-vous pour demain, c'est que ce n'est pas pour aujourd'hui, et celle d'un rendez-vous pour aujourd'hui, c'est son heure. J'ai l'impression de dire des banalités, mais je n'ai pas l'impression que tous les gens qui ont l'amabilité de répondre ici raisonnent comme ça : certains me disent que ça dépend de la façon dont je fait ma requête SQL: puisque je fais une requête sur tous les rendez-vous présents dans la base, ceux d'aujourd'hui ne se différencient pas de ceux pour hier ou pour demain. Ceux pour hier sont obsolètes, ceux pour demain sont à venir, et ceux pour aujourd'hui se rangent en deux catégories : ceux qui sont pour avant l'heure qu'indique ma montre sont obsolètes, et les autres.

Mais je me demande si mon auditoire me suit toujours : je m'arrête à un tout petit détail qui va se résoudre par une ligne de code supplémentaire : on ne va pas passer le réveillon à dessus ! Je me sens comme don Quichotte et ses moulins à vent : je trouve qu'il y a une lacune dans la conception de Python, et j'en fais tout un plat. Je ne changerai pas la face du monde !

Merci à tous.

AMIcalement.

[Sve@r]

je trouve qu'il y a une lacune dans la conception de Python

Tout à fait. C'est un outil humain donc par essence imparfait et lacunaire sur beaucoup de choses... mais certainement pas par rapport à tes besoins, que pour ça Python peut parfaitement gérer.

mais permettez-moi, juste le temps de le dire, d'exprimer le point de vue d'un "intuitionniste"

Exprime toi autant que tu veux, nous on t'écoutera mais ça ne fera pas avancer le schmiliblick. Le souci, c'est que tu ne sembles pas comprendre qu'un ordinateur n'est absolument pas "intuitionniste". Lui il ne sait que traiter des données réelles. Il sait très bien les traiter (les opérer, les comparer) mais ne "devinera" jamais un besoin qui ne lui a pas été exprimé.

un rendez-vous est caractérisé par une date et une heure.

Donc déjà là par exemple, est-ce que tu considères la date d'un côté et l'heure de l'autre... ou bien tu décides que ce sera un "tout compris" ? Pour info Python sait faire les deux (il sait gérer les dates, les heures, et les "dates+heures"). Et SQL aussi. Ne reste donc qu'à faire un choix mais surtout l'exprimer d'une façon que l'ordinateur comprendra.

J'ai l'impression de dire des banalités, mais je n'ai pas l'impression que tous les gens qui ont l'amabilité de répondre ici raisonnent comme ça

Tout à fait. Nous on sait comment un ordinateur gère ses dates donc plutôt que d'essayer de le convertir à notre vision de la chose, on s'adapte nous à sa façon de les voir ce qui est beaucoup plus simple.
Et c'est seulement une fois que les calculs et traitements sont finis qu'on affiche ses résultats dans notre point de vue. Mais libre à toi d'essayer de travailler à contre-courant...

certains me disent que ça dépend de la façon dont je fait ma requête SQL

Hé oui. Il se trouve que SQL sait gérer les dates ET AUSSI qu'il sait gérer les comparaisons de dates. Bien sûr ce n'est pas de la magie, c'est que derrière il y a d'autres experts qui ont oeuvré pour produire un outil capable de. Ne te reste qu'à apprendre comment créer ta table "rendez-vous" avec les bons types de champ pour pouvoir ensuite demander à SQL "s'il te plait, donne moi les rendez-vous qui sont avant (ou après) maintenant". Et tu pourras même lui dire "et aussi ceux qui arrivent dans 1h (dans 2h, dans 3h etc)".

puisque je fais une requête sur tous les rendez-vous présents dans la base, ceux d'aujourd'hui ne se différencient pas de ceux pour hier ou pour demain.

Ah ben oui, ca reste toujours ton rôle d'écrire la bonne requête et on en revient aux fondamentaux: c'est toi qui dirige ton ordinateur et non pas ton ordinateur qui te dirige.

et ceux pour aujourd'hui se rangent en deux catégories : ceux qui sont pour avant l'heure qu'indique ma montre sont obsolètes, et les autres.

Ah là tu fais erreur. Il y a ceux qui sont "avant maintenant" et ceux qui sont "après maintenant". Et c'est même tellement vrai que finalement un ordinateur ne connait que "maintenant" (à prendre dans le sens le plus large du terme). D'ailleurs pourquoi vouloir séparer "date" et "heure" ? Ma remarque sur la gestion du temps sous Unix ne t'a donc pas fait réfléchir ?
Mais encore une fois, SQL (et aussi Python) t'offre des outils permettant de cibler ceux qui sont dans "maintenant +1h", "maintenant +2h", "entre maintenant +1h et maintenant +2h", "maintenant +17jours" etc.

Je me sens comme don Quichotte et ses moulins à vent

Exact. Lui aussi il bitait que dalle à ce à quoi il était confronté. Ceci dit, pour info, thunderbird (outil gratuit pour gérer les mails) intègre aussi un agenda complet.

[wiztricks]

Je me sens comme don Quichotte et ses moulins à vent : je trouve qu'il y a une lacune dans la conception de Python, et j'en fais tout un plat. Je ne changerai pas la face du monde !

Tout l'apprentissage de la programmation est d'arriver à reformuler des problèmes de la vie réelle en algorithmes que pourra traiter la machine. Après vous pouvez avoir les attentes que vous voulez de Python de MySql, des programmeurs ou d'un forum,... mais il va falloir apprendre à faire avec ces réalités là (car on ne va pas réinventer l'informatique juste pour vous...)

puisque je fais une requête sur tous les rendez-vous présents dans la base, ceux d'aujourd'hui ne se différencient pas de ceux pour hier ou pour demain.

C'est parce que votre schéma de données est inadapté au traitement que vous voulez faire. Ce qui n'a rien à voir avec python ou SQL. De plus le schéma d'une base de données est généralement utilisé par plusieurs applications et aura souvent une durée de vie bien plus grande. Du coup, on s'applique à le définir avec soin.... et c'est une spécialité en soi.

- W

[papajoker]

la case de la table pour la date affiche "datetime(2024, 1, 25)" et la case pour l'heure : "datetime.timedelta(seconds=22500)".

On t'a déjà demandé quel est le format de ton champ dans ta base de donnée pas encore de réponse !
Si, je te lis bien, tu as 2 champs et les 2 sont dans un format .... texte
Et pourquoi 2 champs ? génial si on désire compliquer son travail.
Si c'est bien le cas, alors ta structure dans ta table est déjà bien fausse et après il est normal de galérer avec ces représentations texte de dates python.

ceux d'aujourd'hui ne se différencient pas de ceux pour hier ou pour demain. Ceux pour hier sont obsolètes, ceux pour demain sont à venir, et ceux pour aujourd'hui se rangent en deux catégories : ceux qui sont pour avant l'heure qu'indique ma montre sont obsolètes, et les autres.

on avais tous bien compris et c'est un cas extrêmement classique (pour ne pas dire simple) ps: si on a déjà la bonne structure sql ...

[Sve@r]

Si, je te lis bien, tu as 2 champs et les 2 sont dans un format .... texte

Imagine qu'en plus ce soit enregistré à la française... style "16-03-2024" comme par exemple le fait mon syndic...

Va tenter de classer tout ça ensuite...

[L'AMI Yves]

Non, je pense que tu ne me lis pas bien : mon script python lis une table (tout entière) et la place dans une table par un 'fetchall', et (en phase de test) je fais un print() de cette table, et voici le résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
(7, 1, 1, datetime.date(2024, 3, 19), datetime.timedelta(seconds=56400), datetime.timedelta(seconds=55200), 'Epaules', 0, 'Colle', None)
(8, 1, 5, datetime.date(2024, 9, 16), datetime.timedelta(seconds=34200), datetime.timedelta(seconds=33000), 'Révision générale', 0, 'Ruben de Servens', None)
(9, 1, 5, datetime.date(2024, 5, 22), datetime.timedelta(seconds=30600), datetime.timedelta(seconds=29400), 'Oreille', 0, 'Ruben de Servens', None)
(11, 2, 4, datetime.date(2024, 2, 15), datetime.timedelta(seconds=43200), datetime.timedelta(seconds=39000), 'Yeux', 0, 'Inconnu', None)

Quand il y a du texte dans cetet table, il est entouré de guillemets simples, quand il y a des dates, elles sont signalées par "datetime" avec d'autres précisions. Et, dans ma table MySQL, quand je veux que ce soent des dates, je précise 'date' et quand je veux que ce soient des heures, je précise 'time'.

J'ai bien cru comprendre que MySQL était de comprendre les mêmes heures que celles que nous lisons sur nos montres, et tout ce baratin, c'est "juste" pour exprimer ma stupéfaction que ça ne soit jamais arrivé à l'esprit des développeurs de Python;

Comme disait Shakespeare : "Beaucoup de bruit pour rien" (ou presque)

Mais cette discussion est résolue.

AMIcalement.

[Sve@r]

Non, je pense que tu ne me lis pas bien

Ouais, ça doit être ça...

: mon script python lis une table (tout entière) et la place dans une table par un 'fetchall',

Donc là déjà non, fetchall place un résultat dans une liste, pas dans une table. Ca c'était la petite parenthèse de rappel

et (en phase de test) je fais un print() de cette table, et voici le résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
(7, 1, 1, datetime.date(2024, 3, 19), datetime.timedelta(seconds=56400), datetime.timedelta(seconds=55200), 'Epaules', 0, 'Colle', None)
(8, 1, 5, datetime.date(2024, 9, 16), datetime.timedelta(seconds=34200), datetime.timedelta(seconds=33000), 'Révision générale', 0, 'Ruben de Servens', None)
(9, 1, 5, datetime.date(2024, 5, 22), datetime.timedelta(seconds=30600), datetime.timedelta(seconds=29400), 'Oreille', 0, 'Ruben de Servens', None)
(11, 2, 4, datetime.date(2024, 2, 15), datetime.timedelta(seconds=43200), datetime.timedelta(seconds=39000), 'Yeux', 0, 'Inconnu', None)

Quand il y a du texte dans cetet table, il est entouré de guillemets simples, quand il y a des dates, elles sont signalées par "datetime" avec d'autres précisions.

Ben oui, c'est ce que Python montre quand il affiche un tuple contenant divers éléments: il affiche chaque élément dans une syntaxe adaptée à sa nature. Et c'est justement ça qui te montre que ça marche. Quand tu récupères une date au format MySql, l'interface Python/MySQL te la met au format date Python et ainsi tu peux ensuite utiliser les outils Python pour gérer cette date.

Et, dans ma table MySQL, quand je veux que ce soient des dates, je précise 'date' et quand je veux que ce soient des heures, je précise 'time'.

Oui. et si tu veux gérer des rendez-vous (qui supposent alors une gestion date+heure) tu précises "datetime" (en tout cas c'est ce que moi je ferais )

J'ai bien cru comprendre que MySQL était de comprendre les mêmes heures que celles que nous lisons sur nos montres, et tout ce baratin

Ca veut dire quoi "les mêmes heures que celles que nous lisons sur nos montres" ? Il y a combien de types d'heures différentes dans ton univers ???

c'est "juste" pour exprimer ma stupéfaction que ça ne soit jamais arrivé à l'esprit des développeurs de Python;

Là je pige de moins en moins. Python est parfaitement capable de gérer des dates et heures. Si tu rajoute 543 jours, 147 secondes, 812 minutes, 414 heures et 714 semaines à la date du 17 février 2024 23:55:44 il te répond que ça donne le 8 mai 2039 19:30:11. Que te faut-il de plus ???

[papajoker]

Quand il y a du texte dans cetet table, il est entouré de guillemets simples, quand il y a des dates, elles sont signalées par "datetime" avec d'autres précisions. Et, dans ma table MySQL, quand je veux que ce soent des dates, je précise 'date' et quand je veux que ce soient des heures, je précise 'time'.

Beaucoup de baratin pour rien, il suffisait de donner la structure de la table ! (create table ...)

Beaucoup de bruit pour rien

Si je comprends ton analyse ... un champ date du rdv et un champ heure/minute début et un autre heure fin

Donc, toujours le même constat : comment compliquer les choses quand on peut faire simple ...
En fait ce n'est sans doute pas véritablement résolu, tu as plutôt fait des bidouilles/pansements python pour avoir un résultat qui approche ce que tu désires plutôt que t'attaquer véritablement au problème. Et, tu accuses python de ne pas avoir ces bidouilles intégrées ?

Mais, puisque tu ne fournis que du bla-bla et aucun code, il est impossible de savoir ce qui est réellement fait et donc aussi impossible de t'aider réellement, c'est ton choix. Mais alors j'ai du mal à comprendre le pourquoi de ce sujet (Tu as ajouté une simple ligne de code python dans l'application et tu ne désirais pas si j'ai bien compris).

exprimer ma stupéfaction que ça ne soit jamais arrivé à l'esprit des développeurs de Python

Ou alors, il faut peut-être que tu te demandes pourquoi je suis le seul à avoir ce besoin ? un problème xy ? (et le problème X est la structure de ta table )
Tu as résolu le problème Y, bravo

[wiztricks]

J'ai bien cru comprendre que MySQL était de comprendre les mêmes heures que celles que nous lisons sur nos montres, et tout ce baratin, c'est "juste" pour exprimer ma stupéfaction que ça ne soit jamais arrivé à l'esprit des développeurs de Python;

Python affiche (via "print") une représentation d'un objet par défaut. Lorsque c'est un entier ou une chaine de caractères, il est simple d'avoir une idée de ce qu'on s'attend à voir.
Pour les objets plus compliqués, le choix à été de pouvoir reconstruire l'objet.
Par exemple, avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

>>> x = datetime.date(2024, 3, 19)

je vais pouvoir afficher un string:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> str(x)
'2024-03-19'

ou un repr:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> repr(x)
'datetime.date(2024, 3, 19)'

Et si ces défaut ne vous conviennent pas, il faut coder un peu.

Donc c'est arrivé à l'esprit des développeurs Python mais ils ont fait un choix autre que celui qui vous semblait "logique" à vous et il répond à des besoins, une logique qui s'entend aussi bien que la votre (sauf que, dans cette histoire, ce sont les développeurs python qui décident et vous qui ne faites que râler...).

- W