J’ai besoin de l’avis de tous les utilisateurs pour décider quel format nous choisissons pour l’information qui nous donne heure/date du prochain rappel, prochaine alarme, prochain minuteur …
Dans la version stable, pour l’instant, le format est HHmm, donc 1522 pour 15h22.
Dans la version beta, pour l’instant, c’est le format i H d m w Y donc 40 18 20 11 3 2019 pour 18h40 le 20/11/19
Je pensais arriver à utiliser le format CRON pour mettre en « programmation » (déclencheur datée) d’un scénario mais finalement le core n’accepte pas le format, je vais donc faire marche arrière.
Amazon a évolué sa fonctionnalité alarme puisque il n’y a pas longtemps, on ne pouvait pas programmer d’alarme à plus de 24h que l’heure courante (il fallait utiliser rappel), cela a changé récemment. Donc l’information HHmm ne suffit plus, il faut un format complet heure+date.
Conclusion, il faut trouver un format heure/date qui convienne à une majorité d’utilisateur et je ne veux pas faire deux commandes infos (une pour heure et une pour date) par type d’alarme (alarme, alarmemusicale, rappel, minuteur) car cela deviendra incompréhensible pour les utilisateurs.
Perso le format actuel me convient très bien car j’utilise mon echo show 5 comme réveil.
Mais vu l’évolution je comprend qu’il faille rajouter la date mais je vois pas comment je pourrais déclencher mes scenarios à l’heure et date du réveil . Il y a surement une solution mais je ne la connais pas. Il sera alors bien de donner des exemples de comment traiter cela dans un scénario pour ceux qui comme moi ne sont pas des informaticiens.
Bonjour,
Dans la mesure où il sera possible d’utiiser le 2ème format comme standard avec la possibilité de masquer/inhiber ou non la date pour les rappels journaliers, je ne vois pas pourquoi se passer d’un format complet.
Petite question, quand tu dis 40 18 20 11 3 2019, à quoi correspond le 3?
Bonne journée
A ce stade mais le débat mérite d’être lancé, je pense qu’un format :
1033 02122019 pourrait être facile à gérer.
Pour l’utilisation de la date comme déclencheur (comme c’est le cas actuellement sur la version stable), il suffirait de faire quelque chose du genre :
substr(#iciVotreTriggerr#,0,4), à vérifier mais ça devrait donner le format 1033 pour 10h33
Pour la date, faut se creuser un peu plus la cervelle, pour faire un test, est ce que :
substr(#iciVotreTriggerr#,5,8)==#jour##mois##annee# fonctionnerait ?
mmm d’après la doc scenario, ils parlent d’un format pour time_diff :
time_diff(date1,date1[,format]) : Permet de connaître la différence entre 2 dates (les dates doivent être au format AAAA/MM/JJ HH:MM:SS). Par défaut (si vous ne mettez rien pour format), la méthode retourne le nombre total de jours. Vous pouvez lui demander en secondes (s), minutes (m), heures (h). Exemple en secondes time_diff(2018-02-02 14:55:00,2018-02-25 14:55:00,s)
par contre c’est incohérent… ils disent que le format doit être avec « / » et dans l’exemple ils utilisent des « - » …
Je suis pas sur que cela marchera pour 07h33 à cause du 0
À un moment j’avais testé pour 40 18 20 11 3 2019 :
sprintf(« %02d »,trim(substr(#[Cast][Echo Spot][Prochain Minuteur]#, 2, 4)))sprintf(« %02d »,trim(substr(#[Cast][Echo Spot][Prochain Minuteur]#, 0, 2)))
Tu dis ne pas vouloir 2 commandes, mais c’est peut-être la solution la plus simple… Une commune pour la date et une indépendante pour heure de alarme, alarmemusicale, rappel, minuteur
Édit : à non, car problème si plusieurs alarmed à jours différents !
+1 pour moi, c’est un standard que l’on retrouve sur bien d’autres commandes et donc facile à comparer ou transférer sans devoir tout démonter à chaque fois.
Bêta poussée avec nouveau format pour ceux qui veulent tester.
Évidemment, j’ai refait les templates des widgets pour avoir le bon format d’heure à l’écran.
