Juste pour l'aspect didactique :
<?php

function daysIntersection($from1, $to1, $from2, $to2) {
if ($to1 >= $from2 && $to2 >= $from1) { // Intersection des deux périodes
$from = new DateTime(max($from1, $from2));
$to = new DateTime(min($to1, $to2) . ' +1day'); // On ajoute 1 jour, car PHP ne travaille pas sur des journées pleines, mais de minuit à minuit.
$interval = $from -> diff($to);
return $interval -> format('%a');
}
return 0; // Pas d'intersection des deux périodes
}

date_default_timezone_set('Europe/Paris');
echo daysIntersection('2011-01-02', '2011-01-10', '2011-01-08', '2011-01-20');

?>

Notez :
- le test d'intersection simplifié (plus juste aussi, car en tout, il y a 6 cas, l'auteur de la source n'en traite que 5, considérant à tort une configuration comme sans intersection)
- la lisibilité du code (plus facile à comprendre quand on découvre le code)
- la possibilité de formater la période grâce à DateInteval::format() (cf : http://fr.php.net/manual/fr/dateinterval.format.php )

Maintenant, je conçois parfaitement que chacun préfère continuer d'utiliser des méthodes de développement obsolètes et refusent les outils "modernes". Simplement, le code que je présente nécessite PHP5.2, qui est installé même chez Free et OVH, c'est dire si on peut considérer que cette version est la minimum à prendre en compte quand on développe aujourd'hui en PHP. Oubliez un peu le procédural et optimisez votre code, vous verrez, ça fait beaucoup de bien.

C'est vrai, mktime sait utiliser le changement d'heure été/hiver. Il faut passer le 7ème paramètre, celui qui est justement omis dans la source.
Mais comme ce paramètre est obsolète depuis PHP 5.1, il faut utiliser le gestionnaire de fuseau horaire à la place, exactement comme cette source ne le fait pas. Ce qui provoquerait très certainement une erreur de type E_STRICT sur mon serveur.

Je me suis donc mal exprimé : cette source qui utilise mktime, ne prend pas en compte le changement d'heure été/hiver.

Là où je me suis mal exprimé également, c'est sur le fait que cette source, qui se contente de compter les jours en divisant le temps obtenu en secondes par 86400 ne donne pas un résultat pertinent.

Bref : je persiste à dire que les classes DateTime et DateInterval fournissent un résultat bien plus pertinent et avec beaucoup moins de lignes de code... Mais comme cela relèguerait la classe au statut de snippet, on admettra que cette source puisse servir d'exemple pour ce qu'il ne faut pas faire.

En fait, d'après l'exemple donné, ça revient à calculer le nombre de jours entre deux dates : le début de la période 2 et la fin de la période 1.
Par ailleurs, se baser sur mktime() pour se genre de calculs est, rigoureusement, incorrect et donne des valeurs qui sont, rigoureusement, fausses.
En effet, mktime ne prend pas en compte :
- le nombre de jours dans l'année (années bissextiles : rappelons qu'une année tropique conventionnelle dure 365 jours 5 heures 48 minutes 45 secondes)
- le changement d'heure été/hiver

Pour pallier ces problèmes, PHP a introduit dans sa version 5.1 (puis intégré en standard depuis 5.2) les classes DateTime, DatePeriod, DateInterval qui permettent justement de prendre en compte (sous réserve de leur spécifier le fuseau horaire adéquat) les années bissextiles et les changements d'heures.

L'idée est intéressante...
Cependant, un petit coup d'oeil sur Wikipedia te donnera quelques pistes de corrections d'ordre purement orthographique :
http://fr.wikipedia.org/wiki/Nombres_en_français
Par exemple, on écrit quatre-vingts mais on écrit quatre-vingt-trois (avec des traits d'unions, hein)

Où ai-je écrit qu'il ne fallait pas détruire les variables ?
Au contraire ! Il le faut.

MAIS

il faut le faire correctement, c'est à dire en utilisant la fonction unset() et non session_unregister() (pardon, erreur de ma part en recopiant le lien, je voulais dire : http://fr.php.net/session_unregister)
La fonction session_unregister() est obsolète depuis PHP5.3 ce qui signifie qu'elle est amenée à disparaitre.

"mais j'utilise session_unset() pour détruire toutes les variables de la session courante."
Justement : il ne faut pas.

"unset($privilege, $nom, $prenom, $login, $pass); /* c'est lourd, non? */"
Non.
Sinon, il est possible de stocker en session des tableaux associatifs. Ça donnerait :
unset($_SESSION['user_data']); // C'est léger, non ?

On m'a dit un jour que j'étais un peu sec dans mes commentaires (c'est une litote). Bon, c'est vrai, je le reconnais et m'en excuse.
Mais à ma décharge, l'exaspération (entraînée par la lassitude) l'emporte souvent sur le sang-froid.

Si tu avais pris la peine de lire la doc PHP, tu aurais vu que la syntaxe que tu utilises :
while($Entry = @readdir($MyDirectory)) {
n'est pas bonne. Et je ne vais pas m'étendre sur le sujet, parce que je l'ai déjà fait des dizaines de fois et je suis lassé de voir toujours la même chose, mal faite.

Et quand je dis que ta source n'apporte rien de nouveau, je ne me base pas sur ce que tu as écrit, mais sur le fait que, simplement, elle n'apporte rien de nouveau.
On va pas refaire un débat sur "faut-il partager ou non", parce qu'on tournerait en rond. Mais ce que j'ai écrit voulait quand même dire que cette source, n'apportant rien de nouveau, ne mérite pas nécessairement d'être publiée (indépendamment de sa qualité, dont je ne parle pas du tout). C'est pas une critique en soi, juste un constat, toujours le même : phpcs est jonché de sources qui n'apportent rien et qui sont souvent bourrées d'erreurs, de failles, etc. Et c'est dommage, parce qu'au final, ce sont les débutants qui morflent en n'apprenant pas à coder correctement.
Bref, désolé pour la digression.

Sinon c'est pas une source, mais un snippet, ça.
=> http://codyx.org

Vite fait :
    Note:

    Si vous utilisez $_SESSION (ou $HTTP_SESSION_VARS pour PHP 4.0.6 ou plus ancien), utilisez unset() pour détruire une variable de session, i.e. unset($_SESSION['nomvariable']);.

Source : http://es.php.net/session_unset