On Sun, Jan 23, 2000 at 02:31:50AM +0100, Samuel Landau wrote: > > > Bon, moins pratique que la mienne, parce qu'il faut exporter les bonnes > > valeurs, > > puis remettre en place l'environnement. Donc ce que j'ai fait reste > > utile. > > oui, surtout si �a marche mieux que date (qui ne donne pas toutes les > dates, 32 bit sign�s oblige (avant 1902 et apr�s 20??))
Pour cela, pas d'espoir : j'emploie la fonction POSIX strftime(), donc nous sommes dans les m�mes conditions, et dans les limites de POSIX, ces 32bits sign�s sont les valeurs impos�es pour long double. Par contre, je vais apporter deux �am�liorations�. - contrairement � `date' qui, � cause de l'i18n, va mettre LC_TIME en fonction de LC_ALL | LANG | LANGUAGE, `ldate' prendra en compte la valeur par d�faut de LC_TIME sur le serveur ( si vous faites : $LC_TIME=it_IT vous obtenez (en supposant que LC_ALL=fr_FR sur la machine): $date dim jan 23 11:21:22 CET 2000 Il faut faire : $LC_ALL=it_IT $date dom gen 23 11:22:36 CET 2000); - `ldate' travaillera avec une variable d'environnement --- HTTP_MATCHING_LANGUAGE --- positionn�e par le deuxi�me utilitaire `gethal' (GET Http Acceptable Language), pour afficher directement la date en fonction de la langue acceptable par le client et servie (par le... serveur). Il est vrai aussi que la derni�re utilit�, c'est le temps d'ex�cution : `ldate' a le m�me que `date'. Tandis qu'un appel � un script, ou m�me l'encha�nement de commandes shell, ce n'est pas la m�me cat�gorie. > > Mais bon, je crois que je vais me mettre un grand panneau avec le marteau > > barr�, la paire de fesses et la fl�che... > > => GDP!, "bis repetita..." > > bon, il faudrait que je le mette sur ma page ouaibe, il y a une > demi-douzaine de citations maintenant. c'est peu. mais comme il y a > peu de bruit sur cette liste... Pourrais-tu me donner le pointeur quand ce sera fait ? Il est candidat � l'ajout :) A+ -- Thierry LARONDE [EMAIL PROTECTED] website : http://www.polynum.com
