und bevor hier noch Gerüchte entstehen, wir würden Daten von gelöschten Nutzern speichern: Beim Löschen eines Accounts sichern wir den Benutzernamen zusammen mit der Nutzer-ID in einer getrennten Tabelle, damit die Leute, die Nachrichten von diesem User erhalten haben auch später noch sehen können, von wem das kam.
In diesem Fall jetzt kamen noch ein paar interessante Umstände hinzu und wem das hier jetzt schon alles zu nerdig (
http://de.wikipedia.org/wiki/Nerd) ist, der möge an dieser Stelle bitte aufhören zu lesen.
Im Dashboard scheinen noch ein paar alte Verknüpfungen zu gelöschten Usern bestanden zu haben (solche Datenleichen sind i.d.R. kein großes Problem) und das System hat in diesem Fall versucht, zu diesen Nutzer-IDs entsprechende Daten zu holen. Da diese aber nicht mehr vorhanden waren, ist ein System angesprungen, das mit dem neuen Postfach eingeführt wurde, um die alten Nutzernamen transparent aus der anderen Tabelle zu holen. Die restlichen Daten (Geburtstag, etc. blabla) werden in diesem Fall mit Dummydaten aufgefüllt.
Da der Geburtstags-Dashboard-Code aber ein bisschen älter ist als das Postfach hat leider niemand dran gedacht, diese alten Nutzer rauszufiltern. Und so kam, was kommen musste: Die Funktion zum Ermitteln des nächsten Geburtstages hat mit diesen Dummy-Daten gearbeiten und das musste natürlich nach hinten losgehen. Der geneigte PHP-Programmierer darf ja mal raten, was bei folgendem Aufruf für ein Wert rauskommt: mktime(0, 0, 0, null, null, 2010);
Lösung: 1259535600. Was der Unix-Timestamp des 30. November 2009 ist... also nächsten Montag... also "nächste Woche"... tadaa...