Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

fonction de calcul de date

11 views
Skip to first unread message

Miko

unread,
Oct 8, 2006, 5:00:29 PM10/8/06
to
Saut à tous,
Je cherche pour mes neurones racornis et ma flemme grandissante, une
fonction qui renvoie la date au format jj/mm et qui prend en argument le
numéro du jour de l'année (1 - 365) et l'année en cours (2000- 2100 me
suffira....)

Si vous avez ça en magasin...

Miko

unread,
Oct 8, 2006, 5:35:32 PM10/8/06
to
"Miko" ,pris d'une fatigue subite, a écrit :

Heureusement pour moi, le wiki anglophone a des exemples de "clock scan",
que je n'avais jamais utilisé.

% set 1janv [clock scan {01/01/2006}]
1136070000
% set 281 [clock scan {+280 days} -base $1janv]
1160258400
% clock format $281
Sun Oct 08 00:00:00 Paris, Madrid 2006
% clock format $281 -format %c
dimanche 8 octobre 2006 00:00:00

Avec ça, je m'en sortirai ;-)

Miko, racorni plus vite que son ombre.

ulis

unread,
Oct 8, 2006, 5:36:19 PM10/8/06
to

proc dayInYear {day year} \
{
clock scan "[incr day -1] days" -base [clock scan $year-01-01]
}
puts [clock format [dayInYear 91 2006] -format %d/%m]
->01/04

Entre racornis et flemmards... ;-)

ulis
PS: désolé, ça marche aussi pour les autres années

Eric Hassold

unread,
Oct 8, 2006, 7:12:13 PM10/8/06
to
Miko a écrit :

>> le numéro du jour de l'année (1 - 365) et l'année en cours (2000- 2100
>> me suffira....)

Jusqu'au 19 janvier 2038, tout va aller pour toi. Mais si tu veux
vraiment que ca marche jusqu'en 2100, tu vas etre decu avec les clock
scan/format sous Tcl 8.4, pour la simple raison que l'epoch est
represente par un entier 32 bits signe, avec sous la plupart des
machines (pas toutes, mais Linux et Win32 par exemple) le 01/01/1970
comme reference:

% clock format 0
Thu Jan 01 00:00:00 UTC 1970

et que donc le mieux que saura faire clock avec est:

% clock format 0x7fffffff
mar jan 19 04:14:07 CET 2038

qui se gatera avec:

% clock scan {2035-01-01}
2051222400
% clock scan {2040-01-01}
unable to convert date-time string "2040-01-01
% clock format 0x80000000
Fri Dec 13 20:45:52 UTC 1901

La bonne nouvelle, c'est que d'ici la (et esperons un peu avant quand
meme), Tcl 8.5 sera finalise, et que tu pourras profiter de son support
tres etendu des dates, avec enter autre epoch sur 64 bits.

Y'a meme dans 8.5 plein d'autres trucs super "marrants", comme la
localisation geographique (e.g. -locale fr_FR), ou le support du
calendrier julien et gregorien avec gestion correcte du passage de l'un
a l'autre quand on fait justement des "+XXXdays" autour de la date de
basculement, en gerant meme cette date en fonction du pays! Pas
forcement d'un usage courant pour tous, mais cette reecriture from
scratch de la commande "clock" dans Tcl 8.5 vaut vraiment le coup d'oeil.

Eric

Kroc

unread,
Oct 9, 2006, 2:11:54 PM10/9/06
to
Eric Hassold a écrit :

> ... Y'a meme dans 8.5 plein d'autres trucs super "marrants", comme la
> localisation geographique (e.g. -locale fr_FR), ...

Le problème c'est que depuis le temps, 8.5 commence sérieusement à
sentir le vaporware, et je parle même pas du 9.0 :-/

--
David Zolli - Kroc

ulis

unread,
Oct 9, 2006, 2:18:56 PM10/9/06
to
J'ai rajouté l'intervention d'Eric dans le wiki, page "clock"

ulis

Eric Hassold

unread,
Oct 9, 2006, 2:33:41 PM10/9/06
to
Kroc a écrit :

C'est helas tristement exact :-( d'ou mon quelque peu ironique "devrait
etre dispo un peu avant (2038)". Preuve que le mieux peut vraiment etre
l'ennemi du bien.

Eric

Miko

unread,
Oct 9, 2006, 3:18:56 PM10/9/06
to

"Kroc" nous disait...
>Eric Hassold a écrit :

T'inquiètes pas David, Java ne gère les regexp (entres autres) que depuis
peu, on a encore quelques années-lumière d'avance.

Miko et sa soucoupe volante

0 new messages