Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Une fois n'est pas coutume dans le bar, voici le piège à con du mois :-D
Ayant raz la casquette de l'API merdique de PHP concernant le temps, j'ai décidé de me faire des classes propres, avec une interface cohérente et pratique.
Le postulat qui dit que l'on passe au lendemain en ajoutant 24 * 60 * 60 secondes au timestamp courant est faux.
En effet, si on s'attarde un peu sur ton script, on voit que l'exécution part en vrille au moment ou le timestamp atteint 1193522400 (soit le 28 octobre 2007).
Au tour suivant, on arrive à un timestamp de 1193608800.
Or, ce timestamp correspond toujours au 28 octobre 2007.
En effet, le 28 octobre 2007, nous étions le dernier dimanche d'octobre. Et le dernier dimanche de tous les mois d'octobre, nous passons en heure d'hiver : on retire 60 minutes à l'heure courante.
PS : tu dois ton éternelle admiration à un collègue : wako ;) (on a réfléchi chacun de notre côté sur ton soucis)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Ah ben bravo ;)
Je ne pouvais pas me rendre compte que le timstamp changeait, puisqu'avant de l'afficher je le recalcule (dans mon constructeur), ce qui fait que je ne le voyais plus bouger.
Ce n'est qu'en cherchant le timestamp dans Google que je suis tombé sur un forum dans lequel on parlait du changement d'heure.
Je vomis désormais sur Benjamin Franklin, et je le vomirais tant que je penserais au changement d'heure.
Ben moi, dans le for, j'ai var_dumper $day, et j'ai vu que le timestamp de l'objet ne bougeait plus.
Ensuite, j'ai fais un getdate sur le timestamp précédent, et sur celui ou ca merdait.
Dans les deux cas, ca retournait le 28 octobre, le premier à 0h, le deuxième à 23h.
Moi, chuis resté bloqué la dessus. Je pensais en fait à un bug de getdate.
Et c'est mon pote qui m'a dit "passage à l'heure d'hiver".
Ca parait con quand tu as la solution, mais j'avoue être resté perplexe devant ton code pendant 45mn.
Remonter 
