./21 > Il semble que ta solution au problèmes des timestamp 32 bits pour stocker les dates, c'est d'utiliser un INT en MySql, c'est à dire un entier 32 bits ?
Comme je vois le 8 à côté j'imagine que tu voulais un entier 64 bits, donc un BIGINT, ou alors je ne vois vraiment pas… En tout cas c'est une grossière erreur
Pour détailler, la "taille" que tu mets en MySQL à côté du INT (ou de ses copains de tailles différentes), donc le 8 en l'occurence, tu pourrais aussi bien te la mettre dans le cul (pardonne-moi l'expression ) car ça sert juste à dire combien de chiffres afficher au minimum lorsque tu fais une requête en mode texte. (Semble-t-il même que ça ne serve qu'avec l'option zerofill)
C'est juste un design de merde en fait. Car ce que tu voudrais c'est probablement un BIGINT.

(De toutes façons, MySQL pue des pieds dès lors qu'il faut manipuler des dates (je ne dirais pas que ses concurrents sont parfaits à ce niveau, mais la plupart sont suffisamment mieux ). Comme le mentionne Uther, il existe un type DATETIME en MySQL qui est ce que tu devrais utiliser si tu veux un design de base propre. L'efficacité réelle ensuite va dépendre de ta version de MySQL: Apparemment depuis 5.6.4, ils ont mis à jour le système pour que leur type puisse enfin stocker les dates de manière efficace et éventuellement avec une précision inférieure à la seconde.)

./18 > pour le changement d'ordinateur
On a entendu tout le monde paniquer, mais partout ça parlait surtout de correctifs logiciels et de faire attention à bien sauvegarder ses données au cas où le PC ne redémarrerait pas…

Quand au coup du 2038 non préparé, aussi, je pense que ça va être "rigolo"…