Ahoi Sven,
Daraus könnte man jetzt folgern, dass die Verwendung von Datumsfunktionen in SQLite eigentlich eher Sache des aufrufenden Programms sein sollte. Dem würde ich allerdings nicht unbedingt zustimmen. strftime() liefert beliebig schön formatierbare Datumsstrings, und die DB versteht insgesamt 12 verschiedene Datumsformate, so dass eigentlich keine Notwendigkeit besteht, dass die Applikation ihrerseits eine Umrechung in UNIX-Timestamps vornimmt.
Aber strftime() erwartet doch einen Unix-Zeitstempel, welcher in PHP mit der Funktion time() erzeugt wird und die Sekunden seit 1.1.1970 angibt, oder? Mit 2009-03-09 12:11:10 kann ich den nicht füttern, gelle?
Wenn die Unix-Timestamps allerdings unumgänglich sind (was in meinen Augen eher eine schlechte Designentscheidung wäre - Datumsbehandlung würde ich immer möglichst komplett in die DB auslagern, und die Werte in der Applikation nur in alle Richtungen "durchreichen"), dann wird SQLite diese Werte ohnehin als Integer speichern.
Kommt eigentlich eher daher, dass ich mit time() und date() ganz gut hantieren konnte bisher. Auch Verrechnungen mit größer kleiner und ggf. strtotime() oder aber auch 24*60*60*Tagesanzahl machen sich ja ganz galant. Aber Deine Erwägungen haben sicherlich auch was für sich.
Dank und Gruß,