Dates
Yliur
Bonjour
Je tâche de lire des flux de publication (Atom, RSS, ...). Et j'ai donc
cherché comment lire les dates mentionnées dans les flux.
Y a-t-il des bibliothèques assez complètes de gestion de dates en
Lisp ? Disons ce qu'on peut faire avec les classes Date/SimpleDateFormat
de Java par exemple : stockage dans un format "universel", extraction
des différentes composants, lecture/écriture de chaîne représentant une
date dans un format à spécifier (possibilité de passer une chaîne
indiquant le format, genre "jj-MM-aaaa" pour lire et écrire une
date), ... ?
J'ai trouvé net-telent-date, qui est censé lire les dates de la
RFC 822 / RFC 2822 (utilisée dans RSS 2.0 par exemple), mais ça ne
semble pas fonctionner correctement :
(net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT")
-> 3240345601
(net.telent.date:universal-time-to-rfc2822-date
(net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT"))
-> "Sat, 07 Sep 2002 02:00:01 +0200"
Jusque là ça a l'air correct, c'est juste exprimé en UTC+2 plutôt que
UTC (GMT), sans doute en s'appuyant sur les paramètres locaux de la
machine.
Par contre si on refait l'opération une seconde fois ça ne fonctionne
plus.
(net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200")
-> 3240432001
(net.telent.date:universal-time-to-rfc2822-date
(net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200"))
-> "Sun, 08 Sep 2002 02:00:01 +0200"
On dirait que le +0200 à la fin n'a pas été interprété
correctement :( . Ou alors j'ai manqué quelque chose ?
Le problème semble moins important avec la fonction
universal-time-to-rfc-date à la place de
universal-time-to-rfc2822-date, parce que cette fonction renvoie
toujours une date GMT. Mais ce qui m'inquiète c'est que si la date
n'est pas exprimée en UTC/GMT, ça risque de ne pas marcher.
J'ai vu aussi que le stockage de date en Lisp a l'air de reposer sur un
format universel qui consiste à stocker les dates sous forme d'un
nombre entier positif de millisecondes (?) depuis janvier 1900. Donc
pas de date avant 1900. Il n'y a pas de format un peu plus large dans
le langage de base ?
Merci
Yliur
Pascal J. Bourguignon
> J'ai trouvé net-telent-date, qui est censé lire les dates de la
> RFC 822 / RFC 2822 (utilisée dans RSS 2.0 par exemple), mais ça ne
> semble pas fonctionner correctement :
> (net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT")
> -> 3240345601
>
> (net.telent.date:universal-time-to-rfc2822-date
> (net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT"))
> -> "Sat, 07 Sep 2002 02:00:01 +0200"
>
> Jusque là ça a l'air correct, c'est juste exprimé en UTC+2 plutôt que
> UTC (GMT), sans doute en s'appuyant sur les paramètres locaux de la
> machine.
>
> Par contre si on refait l'opération une seconde fois ça ne fonctionne
> plus.
>
> (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200")
> -> 3240432001
>
> (net.telent.date:universal-time-to-rfc2822-date
> (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200"))
> -> "Sun, 08 Sep 2002 02:00:01 +0200"
>
> On dirait que le +0200 à la fin n'a pas été interprété
> correctement :( . Ou alors j'ai manqué quelque chose ?
Il y a peut être une bogue ou un défaut. Revise le code!
Voir aussi: http://common-lisp.net/project/local-time/
> J'ai vu aussi que le stockage de date en Lisp a l'air de reposer sur un
> format universel qui consiste à stocker les dates sous forme d'un
> nombre entier positif de millisecondes (?) depuis janvier 1900. Donc
> pas de date avant 1900. Il n'y a pas de format un peu plus large dans
> le langage de base ?
Non. Le langage Common Lisp n'existait pas avant le 1e Janvier 1900.
D'un autre côté, il est difficile de définir un système cohérent de date
historiques.
Physiquement, il faudrait tenir compte de la relativité (influence de la
gravité et de la vitesse de la Voie Lactée, du Soleil et de la Terre sur
le cône de lumière). En terme de définition des jours, il faudrait
pouvoir reconstituer la durée de chaque jour (secondes intercallaires).
Ensuite historiquement, la notion de calendrier n'est pas universelle.
Rien que pour le calendrier grégorien, son introduction fut différée
selon les pays, donc quand on considère une date dans le passé, il faut
tenir compte du pays ou de la zone d'influence politique où on se place.
http://fr.wikipedia.org/wiki/Passage_au_calendrier_gr%C3%A9gorien
Les fuseaux horraires sont aussi une invention récente (nécessité
seulement par l'introduction du chemin de fer et du télégraphe, premier
moyens de transport et de communication rapides nécessitant une certaine
synchronisation sur de longues distances). Donc avant 1800, pas de
fuseau horraire pour calculer les date: chaque village à midi à son
propre clocher.
Les années A.D. n'on commencé à être utilisées en Europe seulement après
la chûte de l'empire romain. Auparavent, et ailleurs, les années
étaient comptées (et en partant de 1 !!!), par rapport au règne du roi
local, ou dans certains cas, de la fondation de la cité locale.
Donc, bonne chance pour transformer un numéro de secondes en "date"!
(Mais c'est un problème historique intéressant, et il serait amusant
d'implémenter une bibliothèque permettant de faire ces calculs de dates
historiques).
Voir: http://naggum.no/lugm-time.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Damien Wyart
> J'ai vu aussi que le stockage de date en Lisp a l'air de reposer sur
> un format universel qui consiste à stocker les dates sous forme d'un
> nombre entier positif de millisecondes (?) depuis janvier 1900. Donc
> pas de date avant 1900. Il n'y a pas de format un peu plus large dans
> le langage de base ?
C'est sans doute beaucoup plus large que ce que tu cherches, mais tu
peux te renseigner sur la notion de jour julien
(http://fr.wikipedia.org/wiki/Jour_julien) ainsi que sur Calendrica, du
code lisp qui accompagne l'ouvrage de référence "Calendrical
Calculations" :
http://www3.cambridge.org/asia/catalogue/catalogue.asp?isbn=9780521702386&ss=res
Le code de gestion des calendriers dans Emacs est assez proche de
certaines parties de Calendrica (il y a un auteur commun).
Dans ce livre, tous les exemples sont donnés en Lisp, et il y a un
errata qui est à mis à jour régulièrement (important pour les erreurs
dans le code) :
http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/errata.shtml
--
DW
Yliur
"Pascal J. Bourguignon" <p...@informatimago.com> a écrit :
> > Par contre si on refait l'opération une seconde fois ça ne
> > fonctionne plus.
> >
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200")
> > -> 3240432001
> >
> > (net.telent.date:universal-time-to-rfc2822-date
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200"))
> > -> "Sun, 08 Sep 2002 02:00:01 +0200"
> >
> > On dirait que le +0200 à la fin n'a pas été interprété
> > correctement :( . Ou alors j'ai manqué quelque chose ?
>
> Il y a peut être une bogue ou un défaut. Revise le code!
Je vais jeter un oeil.
> Voir aussi: http://common-lisp.net/project/local-time/
Ok, merci pour la référence. Je note ça dans un coin.
> > J'ai vu aussi que le stockage de date en Lisp a l'air de reposer
> > sur un format universel qui consiste à stocker les dates sous forme
> > d'un nombre entier positif de millisecondes (?) depuis janvier
> > 1900. Donc pas de date avant 1900. Il n'y a pas de format un peu
> > plus large dans le langage de base ?
>
> Non. Le langage Common Lisp n'existait pas avant le 1e Janvier 1900.
>
> D'un autre côté, il est difficile de définir un système cohérent de
> date historiques.
>
> [... (plein de remarques intéressantes)]
>
> Donc, bonne chance pour transformer un numéro de secondes en "date"!
> (Mais c'est un problème historique intéressant, et il serait amusant
> d'implémenter une bibliothèque permettant de faire ces calculs de
> dates historiques).
>
> Voir: http://naggum.no/lugm-time.html
Oui, les remarques sont justes. Mais je ne vais pas me lancer dans ce
genre de bibliothèque :) .
Merci
Yliur
Damien Wyart <damien...@free.fr> a écrit :
> * Yliur <yl...@free.fr> in fr.comp.lang.lisp:
> > J'ai vu aussi que le stockage de date en Lisp a l'air de reposer sur
> > un format universel qui consiste à stocker les dates sous forme d'un
> > nombre entier positif de millisecondes (?) depuis janvier 1900. Donc
> > pas de date avant 1900. Il n'y a pas de format un peu plus large
> > dans le langage de base ?
>
> C'est sans doute beaucoup plus large que ce que tu cherches, mais tu
> peux te renseigner sur la notion de jour julien
> (http://fr.wikipedia.org/wiki/Jour_julien) ainsi que sur Calendrica,
> du code lisp qui accompagne l'ouvrage de référence "Calendrical
> Calculations" :
> http://www3.cambridge.org/asia/catalogue/catalogue.asp?isbn=9780521702386&ss=res
Oui, je vais plutôt faire simple :) . Les dates que j'ai à lire seront
plutôt des dates actuelles, ça devrait être possible de rester dans un
cadre assez restreint.
Merci pour les liens.
Pascal J. Bourguignon
> Oui, je vais plut�t faire simple :) . Les dates que j'ai � lire seront
> plut�t des dates actuelles, �a devrait �tre possible de rester dans un
> cadre assez restreint.
Ainsi tu as la r�ponse � ta question, pourquoi Common Lisp ne traite les
temps que comme nombres de secondes depuis le 1er Janvier 1900.
Yliur
"Pascal J. Bourguignon" <p...@informatimago.com> a écrit :
> Yliur <yl...@free.fr> writes:
>
> > Oui, je vais plutôt faire simple :) . Les dates que j'ai à lire
> > seront plutôt des dates actuelles, ça devrait être possible de
> > rester dans un cadre assez restreint.
>
> Ainsi tu as la réponse à ta question, pourquoi Common Lisp ne traite
> les temps que comme nombres de secondes depuis le 1er Janvier 1900.
Ça me rappelle cette illustration sur le site des geekscottes :)
http://www.nojhan.net/geekscottes/index.php?id=103
Yliur
"Pascal J. Bourguignon" <p...@informatimago.com> a �crit :
> Yliur <yl...@free.fr> writes:
>
> > J'ai trouv� net-telent-date, qui est cens� lire les dates de la
> > RFC 822 / RFC 2822 (utilis�e dans RSS 2.0 par exemple), mais �a ne
> > semble pas fonctionner correctement :
>
>
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT")
> > -> 3240345601
> >
> > (net.telent.date:universal-time-to-rfc2822-date
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 00:00:01 GMT"))
> > -> "Sat, 07 Sep 2002 02:00:01 +0200"
> >
> > Jusque l� �a a l'air correct, c'est juste exprim� en UTC+2 plut�t
> > que UTC (GMT), sans doute en s'appuyant sur les param�tres locaux
> > de la machine.
> >
> > Par contre si on refait l'op�ration une seconde fois �a ne
> > fonctionne plus.
> >
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200")
> > -> 3240432001
> >
> > (net.telent.date:universal-time-to-rfc2822-date
> > (net.telent.date:parse-time "Sat, 07 Sep 2002 02:00:01 +0200"))
> > -> "Sun, 08 Sep 2002 02:00:01 +0200"
> >
> > On dirait que le +0200 � la fin n'a pas �t� interpr�t�
> > correctement :( . Ou alors j'ai manqu� quelque chose ?
>
> Il y a peut �tre une bogue ou un d�faut. Revise le code!
J'ai regard� le code et trouv� une erreur me semble-t-il. En tout cas
quand je modifie le code le test pr�c�dent r�ussit :) .
J'ai r�ussi � contacter la personne � l'origine de cette biblioth�que,
mais il a affirm� ne plus la maintenir.
J'ai trouv� la biblioth�que sur CLiki. Une suggestion sur la "meilleure"
fa�on de proc�der ? Est-il possible de modifier la biblioth�que et de
poster une nouvelle version sur CLiki sans plus de formalit� ?