| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Ce paramètre est devenu inutile depuis l’ajout des sources, qui sont
déjà triées par leur ID.
|
|
|
|
|
|
|
|
|
|
Mise à jour de la doc, nouvelles protections dans timetable_common()
|
|
|
|
Depuis la séparation entre source et emploi du temps, timetable.url
contient le lien vers la liste des groupes de la page, et donc ici
pointe sur lui-même.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
parties entre parenthèse. Les nouveaux cas de tests passent avec succès.
|
|
|
|
possédant pas de semestre. Les tests rajoutés au commit précédent
passent donc avec succès.
|
|
erreurs de parsage. Ces erreurs sont liées au fait qu’elles ne
possèdent pas de semestre.
Exemple avec le groupe M1 GC (toutes sections et semestres
confondus) :
Attendu :
* mention : M1 GC
* semestre :
* sous-groupe :
Obtenu avec la regex actuelle :
* mention : M1
* semestre :
* sous-groupe : C
|
|
parties entre parenthèse. Les nouveaux cas de tests passent avec succès.
|
|
|
|
|
|
|
|
|
|
possédant pas de semestre. Les tests rajoutés au commit précédent
passent donc avec succès.
|
|
erreurs de parsage. Ces erreurs sont liées au fait qu’elles ne
possèdent pas de semestre.
Exemple avec le groupe M1 GC (toutes sections et semestres
confondus) :
Attendu :
* mention : M1 GC
* semestre :
* sous-groupe :
Obtenu avec la regex actuelle :
* mention : M1
* semestre :
* sous-groupe : C
|
|
|
|
datetime.combine()"
This reverts commit 37d80d84d8ce6cb0a17a0e4179e4c7a453f7fcc2.
|
|
|
|
|
|
|
|
|
|
|
|
cours d’une salle pour économiser les requêtes et augmenter les performances
|
|
rapide à exécuter sur de gros volumes de données. On aura peut-être
besoin d’utiliser un double index pour augmenter encore plus les
performances.
La requête liste tous les cours commençant avant la fin de
l’intervalle et finissant après le début de l’intervalle, en excluant
les cours n’ayant pas de salle assignée. On récupère ensuite la liste
des salles de ces cours, et on inverse le contenu de la liste. On trie
ensuite les cours par leur nom.
|
|
Pour chaque salle, on compte tous les cours commençant avant la fin de
l’intervalle entré par l’utilisateur et finissant après le début de
cet intervalle. Tous les cours correspondant à cette requête
se trouvent au moins en partie sur l’intervalle.
On sélectionne ensuite les salles n’ayant pas de cours correspondant à
la requête précédente.
|
|
On y créée sept salles, avec différents agencements de cours :
0. Le cours se finit dans l’intervalle sélectionné
1. Le cours se commence dans l’intervalle
2. Combinaison de 0. et de 1.
3. Le cours commence avant et fini après l’intervalle
4. Le cours commence et fini pendant l’intervalle
5. Un cours se finit avant et un autre commence après
6. Aucun cours
liste des salles.
Normalement, seules les salles des cas cinq et six doivent se
retrouver dans la liste des salles.
|
|
|
|
|
|
|
|
Pour cela, on avait besoin d’insérer un objet vTimezone dans l’en-tête
du fichier, ce qui est assez fastidieux. À la place, on met une
valeur x-wr-timezone dans les en-têtes.
Ajout de valeurs calscale, method, x-wr-calname et x-wr-caldesc aux ICS.
Revert "Bon fuseau horaire dans les ICS."
This reverts commit e2bc777f7f988cba945c027aaa27d98aa3913a71.
|
|
Pour cela, on avait besoin d’insérer un objet vTimezone dans l’en-tête
du fichier, ce qui est assez fastidieux. À la place, on met une
valeur x-wr-timezone dans les en-têtes.
Ajout de valeurs calscale, method, x-wr-calname et x-wr-caldesc aux ICS.
Revert "Bon fuseau horaire dans les ICS."
This reverts commit e2bc777f7f988cba945c027aaa27d98aa3913a71.
|
|
|
|
Les bases de données stockent et renvoient seulement des dates en
UTC. Django inscrit cette information dans les objets datetime, par
conséquent les dates inscrites sur les templates étaient
automatiquement converties à l’heure indiquée dans la configuration.
Or, les ICS sont générées avec une librairie tierce (icalendar), et ne
tient donc pas compte de la configuration de Django. Le module inscrit
donc des dates UTC dans les ICS. C’est sans conséquences, car l’heure
est correcte, juste décalée avec une information de fuseau horaire. Un
bon client iCalendar est censé convertir les heures de lui-même en
fonction des préférences du systèmes. Seulement certains d’entre eux
affichent aussi le fuseau horaire d’origine.
|
|
Les bases de données stockent et renvoient seulement des dates en
UTC. Django inscrit cette information dans les objets datetime, par
conséquent les dates inscrites sur les templates étaient
automatiquement converties à l’heure indiquée dans la configuration.
Or, les ICS sont générées avec une librairie tierce (icalendar), et ne
tient donc pas compte de la configuration de Django. Le module inscrit
donc des dates UTC dans les ICS. C’est sans conséquences, car l’heure
est correcte, juste décalée avec une information de fuseau horaire. Un
bon client iCalendar est censé convertir les heures de lui-même en
fonction des préférences du systèmes. Seulement certains d’entre eux
affichent aussi le fuseau horaire d’origine.
|
