[SPIP Zone] Sphinx (Indexer) et dates 32 bits

Salut,

j’attire l’attention de toutes les personnes intéressées par le développement du plugin Indexer/Sphinx sur le fait que j’ai commencé à faire pas mal de corrections et ajouté quelques améliorations.

Un point très délicat est celui de la gestion des dates : j’ai fait un wiki sur le sujet:
https://contrib.spip.net/Indexer-date-32bits

Je pense qu’il faut qu’on fasse un choix collectivement histoire de continuer à partager le développement, mais sur ce point c’est un peu difficile de trancher :

=> passer en bigint solutionne le problème d’étendue des dates (sinon on est bloqués à 1970-2038).
=> mais complique la vie si on veut utiliser YEAR() / YEARMONTH()

Il y a peut-être d’autres choses à faire pour améliorer ça, par exemple intégrer notre propre définition de YEAR() dans le compilo (??).

Le 09.02.17 à 12:33, Fil a écrit :

Salut,

j'attire l'attention de toutes les personnes intéressées par le
développement du plugin Indexer/Sphinx sur le fait que j'ai commencé à
faire pas mal de corrections et ajouté quelques améliorations.

Un point très délicat est celui de la gestion des dates : j'ai fait un
wiki sur le sujet:
Indexer-date-32bits

Je pense qu'il faut qu'on fasse un choix collectivement histoire de
continuer à partager le développement, mais sur ce point c'est un peu
difficile de trancher :

=> passer en bigint solutionne le problème d'étendue des dates (sinon on
est bloqués à 1970-2038).
=> mais complique la vie si on veut utiliser YEAR() / YEARMONTH()

Il y a peut-être d'autres choses à faire pour améliorer ça, par exemple
intégrer notre propre définition de YEAR() dans le compilo (??).

-- Fil

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

je me dis que c'est le genre de chose qui devrait se discuter avec les gens de SPHINX non? ca doit être un problème "classique", non?

Sinon, une solution est de stocker doublement?

--
Maïeul