calcul de temps

Philippe Gras

01/08/2014 à 15:40

Le 1 août 14 à 13:29, Sylvain L. Sauvage a écrit :

Le hic, cest quune durée ça nest pas une date et quil ny
a pas de fonction de base pour ça. Donc il faut bien soit
calculer soi-même (ce que moi-meme appelle bidouillage ?

Oui, c'est exact. Je me suis pris la tête récemment en PHP sur
une question similaire, et calculer une durée d'après une date.

Mais ce n'était pas en bash Désolé !

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Francois Lafont

01/08/2014 à 15:40

Le 01/08/2014 13:29, Sylvain L. Sauvage a écrit :

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

Oui, du peu que l’on en connaisse, la question originale (une
fois correctement lue) pouvait se traiter en (ba)sh seul :
calcul et formatage de (j, h, m, s) à partir d’un nombre de
secondes.

Et même à partir de chaînes en format « date », on
peut le faire avec la commande "date" (version GNU) :

--------------------------------------------
#!/bin/sh

a='2014-04-02 19:31:07 CEST'
b='2014-08-01 09:57:15 CEST'

# In seconds.
a=$(date -d "$a" '+%s')
b=$(date -d "$b" '+%s')

diff=$(( b - a ))
days=$(( diff / 86400 ))
rest=$(( diff - days * 86400 ))
hours=$(( rest / 3600 ))
rest=$(( rest - hours * 3600 ))
minutes=$((rest / 60 ))
seconds=$(( rest - minutes * 60 ))

printf "%s day(s) %s hour(s) %s minute(s) and %s second(s)n" "$days" "$hours" "$minutes" "$seconds"
--------------------------------------------

Après ça reste assez moche effectivement. En revanche,
l'équivalent en Perl (ou en tout autre langage de
script dans le même genre) sera certainement plus long
au niveau du temps d'exécution (toujours à cause du
chargement de l'interpréteur).

Le hic, c’est qu’une durée ça n’est pas une date et qu’il n’y
a pas de fonction de base pour ça. Donc il faut bien soit
calculer soi-même (ce que moi-meme appelle bidouillage ? ou
alors parlait-il de bidouiller la sortie de `date` pour enlever
le jour de trop ?), soit utiliser quelque chose qui sache qu’une
durée c’est différent d’une date. Et ce quelque chose, c’est une
bibliothèque, pour Perl, C, ou autre. D’où le fait que moi-meme
n’a trouvé que des références à Perl, C, Java… et le fait que,
moi-même (notez l’accent ;o), voyant des manipulations de dates,
une réticence à utiliser un vrai langage et une proposition
d’utiliser un interprète bridé, ai couru à la défense de
l’utilisation d’un vrai interprète…

Je comprends et encore une fois je suis totalement
d'accord.

Le shell, ça va bien un peu mais ça devient vite difficile
à maintenir

D'accord avec ça également.

et très gourmand en processus inutiles.

Là aussi, j'ajoute un bémol. Parfois le shell peut
s'avérer plus rapide qu'un autre interpréteur (comme Perl
ou autre) sur des petits programmes assez simples et courts
car, dans le temps d'exécution, il faut compter le temps
de chargement de l'interpréteur lui-même, […]

Ok mais il y avait le mot-clef « devient ».

Ah oui, désolé. On est d'accord alors et dans ce cas ma
remarque est plus un petit complément qu'un bémol. ;)

Ma conclusion
généralisait : le shell, c’est très bien comme glu (traitement
par lot, tubes, quelques variables, etc.) mais, souvent, le
problème se complexifie et, en bash, on se met alors à
compliquer le script : on utilise de plus en plus de petits
programmes simples (sed, grep, cut…) pour contourner les manques
du shell alors qu’un seul processus interprète suffirait et
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

Oui, tout à fait d'accord. Quand on commence à faire
du sed, grep, cut, tail, awk dans tous les sens, c'est
qu'il est temps de passer à un langage de script un peu
plus évolué avec davantage de structures de données etc.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/lrg4uj$ilj$

Le 01/08/2014 13:29, Sylvain L. Sauvage a écrit :

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

Oui, du peu que l’on en connaisse, la question originale (une
fois correctement lue) pouvait se traiter en (ba)sh seul :
calcul et formatage de (j, h, m, s) à partir d’un nombre de
secondes.

Et même à partir de chaînes en format « date », on
peut le faire avec la commande "date" (version GNU) :

--------------------------------------------
#!/bin/sh

a='2014-04-02 19:31:07 CEST'
b='2014-08-01 09:57:15 CEST'

# In seconds.
a=$(date -d "$a" '+%s')
b=$(date -d "$b" '+%s')

diff=$(( b - a ))
days=$(( diff / 86400 ))
rest=$(( diff - days * 86400 ))
hours=$(( rest / 3600 ))
rest=$(( rest - hours * 3600 ))
minutes=$((rest / 60 ))
seconds=$(( rest - minutes * 60 ))

printf "%s day(s) %s hour(s) %s minute(s) and %s second(s)n" "$days" "$hours" "$minutes" "$seconds"
--------------------------------------------

Après ça reste assez moche effectivement. En revanche,
l'équivalent en Perl (ou en tout autre langage de
script dans le même genre) sera certainement plus long
au niveau du temps d'exécution (toujours à cause du
chargement de l'interpréteur).

Le hic, c’est qu’une durée ça n’est pas une date et qu’il n’y
a pas de fonction de base pour ça. Donc il faut bien soit
calculer soi-même (ce que moi-meme appelle bidouillage ? ou
alors parlait-il de bidouiller la sortie de `date` pour enlever
le jour de trop ?), soit utiliser quelque chose qui sache qu’une
durée c’est différent d’une date. Et ce quelque chose, c’est une
bibliothèque, pour Perl, C, ou autre. D’où le fait que moi-meme
n’a trouvé que des références à Perl, C, Java… et le fait que,
moi-même (notez l’accent ;o), voyant des manipulations de dates,
une réticence à utiliser un vrai langage et une proposition
d’utiliser un interprète bridé, ai couru à la défense de
l’utilisation d’un vrai interprète…

Je comprends et encore une fois je suis totalement
d'accord.

Le shell, ça va bien un peu mais ça devient vite difficile
à maintenir

D'accord avec ça également.

et très gourmand en processus inutiles.

Là aussi, j'ajoute un bémol. Parfois le shell peut
s'avérer plus rapide qu'un autre interpréteur (comme Perl
ou autre) sur des petits programmes assez simples et courts
car, dans le temps d'exécution, il faut compter le temps
de chargement de l'interpréteur lui-même, […]

Ok mais il y avait le mot-clef « devient ».

Ah oui, désolé. On est d'accord alors et dans ce cas ma
remarque est plus un petit complément qu'un bémol. ;)

Ma conclusion
généralisait : le shell, c’est très bien comme glu (traitement
par lot, tubes, quelques variables, etc.) mais, souvent, le
problème se complexifie et, en bash, on se met alors à
compliquer le script : on utilise de plus en plus de petits
programmes simples (sed, grep, cut…) pour contourner les manques
du shell alors qu’un seul processus interprète suffirait et
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

Oui, tout à fait d'accord. Quand on commence à faire
du sed, grep, cut, tail, awk dans tous les sens, c'est
qu'il est temps de passer à un langage de script un peu
plus évolué avec davantage de structures de données etc.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/lrg4uj$ilj$1@ger.gmane.org

Vous avez filtré cet utilisateur ! Consultez son message

Le 01/08/2014 13:29, Sylvain L. Sauvage a écrit :

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

Oui, du peu que l’on en connaisse, la question originale (une
fois correctement lue) pouvait se traiter en (ba)sh seul :
calcul et formatage de (j, h, m, s) à partir d’un nombre de
secondes.

Et même à partir de chaînes en format « date », on
peut le faire avec la commande "date" (version GNU) :

--------------------------------------------
#!/bin/sh

a='2014-04-02 19:31:07 CEST'
b='2014-08-01 09:57:15 CEST'

# In seconds.
a=$(date -d "$a" '+%s')
b=$(date -d "$b" '+%s')

diff=$(( b - a ))
days=$(( diff / 86400 ))
rest=$(( diff - days * 86400 ))
hours=$(( rest / 3600 ))
rest=$(( rest - hours * 3600 ))
minutes=$((rest / 60 ))
seconds=$(( rest - minutes * 60 ))

printf "%s day(s) %s hour(s) %s minute(s) and %s second(s)n" "$days" "$hours" "$minutes" "$seconds"
--------------------------------------------

Après ça reste assez moche effectivement. En revanche,
l'équivalent en Perl (ou en tout autre langage de
script dans le même genre) sera certainement plus long
au niveau du temps d'exécution (toujours à cause du
chargement de l'interpréteur).

Le hic, c’est qu’une durée ça n’est pas une date et qu’il n’y
a pas de fonction de base pour ça. Donc il faut bien soit
calculer soi-même (ce que moi-meme appelle bidouillage ? ou
alors parlait-il de bidouiller la sortie de `date` pour enlever
le jour de trop ?), soit utiliser quelque chose qui sache qu’une
durée c’est différent d’une date. Et ce quelque chose, c’est une
bibliothèque, pour Perl, C, ou autre. D’où le fait que moi-meme
n’a trouvé que des références à Perl, C, Java… et le fait que,
moi-même (notez l’accent ;o), voyant des manipulations de dates,
une réticence à utiliser un vrai langage et une proposition
d’utiliser un interprète bridé, ai couru à la défense de
l’utilisation d’un vrai interprète…

Je comprends et encore une fois je suis totalement
d'accord.

Le shell, ça va bien un peu mais ça devient vite difficile
à maintenir

D'accord avec ça également.

et très gourmand en processus inutiles.

Là aussi, j'ajoute un bémol. Parfois le shell peut
s'avérer plus rapide qu'un autre interpréteur (comme Perl
ou autre) sur des petits programmes assez simples et courts
car, dans le temps d'exécution, il faut compter le temps
de chargement de l'interpréteur lui-même, […]

Ok mais il y avait le mot-clef « devient ».

Ah oui, désolé. On est d'accord alors et dans ce cas ma
remarque est plus un petit complément qu'un bémol. ;)

Ma conclusion
généralisait : le shell, c’est très bien comme glu (traitement
par lot, tubes, quelques variables, etc.) mais, souvent, le
problème se complexifie et, en bash, on se met alors à
compliquer le script : on utilise de plus en plus de petits
programmes simples (sed, grep, cut…) pour contourner les manques
du shell alors qu’un seul processus interprète suffirait et
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

Oui, tout à fait d'accord. Quand on commence à faire
du sed, grep, cut, tail, awk dans tous les sens, c'est
qu'il est temps de passer à un langage de script un peu
plus évolué avec davantage de structures de données etc.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/lrg4uj$ilj$

andre_debian

01/08/2014 à 17:40

Sinon, il y a plus simple, un Epoch Converter :

http://www.epochconverter.com/

et en temps rÃ©el :
http://www.epochconverter.com/epoch/clock.php

Le code source de la page indique la mÃ©thode du calcul...

AndrÃ©

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

moi-meme

01/08/2014 à 18:50

Le Fri, 01 Aug 2014 12:20:01 +0200, Stéphane GARGOLY a écrit :

Attention, aussi, au passage de l'heure d'hiver à l'heure d'été (et vice
versa).

si c'est en epoch il n'y a pas d'heure d'été ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/53dbbeef$0$1998$

moi-meme

01/08/2014 à 19:00

Le Thu, 31 Jul 2014 22:30:02 +0200, moi-meme a écrit :

encore un question tordue, je m'en excuse.

Pas trouvé de réponse sauf en PERL ou en C ou java mais je suis dans du
bash.

j'ai 2 dates epoch par exemple : 1406779635 et 1406484823

Jeopeux avoir leur valeur vraie par
moi$ date -d @1406779635
jeudi 31 juillet 2014, 06:07:15 (UTC+0200) et
moi$ date -d @1406484823
dimanche 27 juillet 2014, 20:13:43 (UTC+0200)

mais la différence de temps je ne vois pas comment la sortir la
différence est de : 294812
moi$ date +"%d jours %H heures %M minutes %S secondes" -d @294812 04
jours 10 heures 53 minutes 32 secondes

Ya un jour de trop. C'est normal la différence est toujours une date et
le calendrier ne démarre pas au 0 Janvier :-)

Question con : est -il possible de calculer le temps entre 2 epoch sans
bidouille ?

(calcul du nombre de jours, enlever nb jours*(60*60/24) pour trouver le
nombre d'heures, etc)

Merci pour toute proposition.
C Hiebel

J'en tire les conclusions suivantes :
Les manières d'y arriver en Perl ou en Bash sont compliquées au possible.

Je vais me faire un petit script bash externe :
- en entrée la différence epoch
- en sortie nb jours, nb heures, nb nminutes et nb secondes.

AMHA c'est le plus simple :-)

Je suis surpris qu'il n'y a pas de solution toute faite. C'est étonnant
car ce n'est pas nouveau et beaucoup de gens l'ont côtoyé. Je croyais
qu'il y avait toujours un utilitaire dispo, j'ai trouvé une faille.

Merci pour vos réponses.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/53dbc192$0$1998$

Francois Lafont

01/08/2014 à 19:20

Le 01/08/2014 18:34, moi-meme a écrit :

J'en tire les conclusions suivantes :
Les manières d'y arriver en Perl ou en Bash sont compliquées au possible.

Ah ? 10 lignes de shell, ça ne me semble pas
si « compliqué au possible » que ça.

Je vais me faire un petit script bash externe :
- en entrée la différence epoch
- en sortie nb jours, nb heures, nb nminutes et nb secondes.

Une simple fonction dans ton script shell
principal ferait tout aussi bien l'affaire.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/lrghkg$s09$

moi-meme

01/08/2014 à 22:30

Le Fri, 01 Aug 2014 19:20:02 +0200, Francois Lafont a écrit :

Le 01/08/2014 18:34, moi-meme a écrit :

J'en tire les conclusions suivantes : Les manières d'y arriver en Perl
ou en Bash sont compliquées au possible.

Ah ? 10 lignes de shell, ça ne me semble pas si « compliqué au possible
» que ça.

en shell non mais en perl j'ai bien aimé :
s/(d+)([a-z]+)(d*)$/$1 $2 $3/i; $i2 =~ s/(d+)([a-z]+)(d*)$/$1 $2 $3/i;

Je vais me faire un petit script bash externe : - en entrée la
différence epoch
- en sortie nb jours, nb heures, nb nminutes et nb secondes.

Une simple fonction dans ton script shell principal ferait tout aussi
bien l'affaire.

Ça se vaut.

le problème sera de retrouver si j'en ai de nouveau besoin :-)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/53dbf24a$0$2370$

calcul de temps

7 réponses

Veuillez sélectionner un problème