Produits Entr'ouvert » w.c.s.

Quand j'essaie de lister mes usages principaux (quasi exclusifs en fait), ça donne :

• Envoyer un mail x jours avant une date donnée (date de rendez-vous)
• Comparer deux dates
• Ajouter/soustraire des jours à une date

Et du coup c'est ça qui devrait être simple/magique. Alors je mets ce que je trouve simple comme syntaxe pour ces 3 exemples, sans présager de la faisabilité (parce que j'ai conscience de mon ignorance).

* form_var_date_envoi == form_var_date_rendez_vous|sub:2
* form_var_date1 == form_var_date2 ou form_var_date1 > form_var_date2
* form_var_date == form_var_date|add:10

Et encore plus simple et sans doute encore moins possible, se serait un filtre unique calc ou calc_date, me permettant de faire |calc_date:"+1" ou |calc_date:"-2"

Pierre Cros a écrit :

• form_var_date_envoi form_var_date_rendez_vous|sub:2
• form_var_date1 form_var_date2 ou form_var_date1 > form_var_date2
• form_var_date == form_var_date|add:10

Malheureusement les dates sont stockées sous forme de chaîne de caractères dont le format n'est pas connu, voire d'autres formats, et ça peut être "21/12/2017" ou "2017-12-21" ou "2017-12-21 10:30"... du coup impossible de faire des comparaisons ou des traitements. Il faut passer par de la conversion en objet de type "date", et donc ça donnerait :

* form_var_date_envoi|date == form_var_date_rendez_vous|date|sub:2
* form_var_date1|date == form_var_date2|date ou form_var_date1|date > form_var_date2|date
* form_var_date|date == form_var_date|date|add:10

Ce qui me semble presque explicable, j'imagine quelque chose dans la doc comme : « Quand vous devez comparer des dates ou faire des calculs sur les dates, vous devez d'abord convertir les données en "objet date". Pour cela, après le nom de la variable, ajoutez le filtre "|date". » Et avec des exemples ensuite.

Par ailleurs dans le patch ci-dessus, add permet d'ajouter des minutes ou des heures à des objets de type "datetime", plus précis que la date. Par exemple pour envoyer un mail 24h avant un rendez-vous : « form_var_rdv|datetime|sub:"24h" » qui sera à comparer avec « now|datetime ».

En vrac, dans différentes directions,

• si les types doivent être explicites, il faut que la notion soit acceptée/assimilée, pour ensuite être bien exposée dans la documentation;

• si le seul truc qui empêche de commencer l'opération add par un parse_date est l'argument form_var_date|add:2 < now, non comparaison date/datetime, je dirais que ça se joue là en deux parties : 1/ la date c'est "today", pas "now", 2/ peut-on exploiter LazyFieldVarDate, pour se donner de la marge sur les opérateurs ?

• perso je trouverais plus simple d'avoir add_years/add_days/add_minutes que add: + quantité et unité, plus simple d'expliquer qu'à une date tu peux ajouter des années (add_years), des jours (add_days), des minutes (add_minutes), que d'avoir un gros pavé décrivant tout ce qui peut être tapé dans "add", avec des risques d'explications impossibles parce que "magie".
  • ça permet aussi d'avoir des enchainemente, façon form_date_plop|add_days:2|add_minutes:60, alors que si on part sur un add magique, je crains qu'on tende vers form_var_plop|add:"2d60m".

J'ai édité mon message parce que les

==

Pour moi l'ajout d'heures ou de minutes c'est un truc tout à fait accessoire, je ne l'ai jamais utilisé. Alors ça ne me gênerait pas que ça reste compliqué (pour les gens qui aiment bien se compliquer la vie pour rien), tandis que les opérations sur les jours resteraient simples.

Je trouve que spécifier l'unité dans add me semble plus clair (et ça évite un cast explicite que les gens oublieront), je met mon +1 sur |add_day(s):x.

À relire, l'import de copy est inutile.