Dès lors qu’une application est utilisée à différents endroits du globe, il faut gérer le stockage et l’affichage des dates selon les timezones.

La première question qui vient est : quelle référence de temps utilise t-on ?

Si l’application stocke les dates selon la timezone de l’utilisateur qui créé un contenu, il peut vite devenir difficile de convertir cette date dans la timezone de l’utilisateur qui va consulter ce contenu.

Une solution (pourrie) pourrait être de calculer le différentiel entre la timezone du créateur et celle du lecteur. On imagine le casse tête.

Je pense que le bon pattern consiste à stocker systématiquement les dates sous forme de timestamp calculés sur une base GMT ou UTC, grâce à la fonction time(), et à les afficher avec la fonction date() qui prend en compte la

timezone système PHP (valuée avec date_default_timezone_set).

Le problème n’est qu’à moitié résolu.

Imaginons une application de calcul de statistiques qui stocke des données tous les jours, à 23h, en indexant chaque entrée sur le timestamp correspondant à l’heure du calcul.

Exemple :

Je suis en France et je consulte les statistiques du jour avec le timestamp de référence suivant :

mktime(23, 59, 0, date(“m”), date(“d”), date(“y”));

Hiro est au Japon et consulte les statistiques en recherchant les entrées possédant ce timestamp de référence. Et bien il n’en trouvera pas….

Car le résultat du mktime n’est pas le même.

Pour être sûr de convertir des dates en timestamp sur les même bases, il faut utiliser une fonction méconnue en php :

gmmktime

Elle s’utilise de la même manière mais calcule tout sur une base GMT.

Donc pour résumer :

- les dates sont stockées en GMT

- elles sont affichées avec date(), en ayant précédemment valué date_default_timezone_set

- les converstions date -> timestamp se font avec gmmktime au lieu de mktime

Je suis preneur de vos retours.

Happy coding

You made my day dude !

C’est ce que j’aurais dis à Hannes Magnusson, développeur systèmes en Suède, quand j’ai lu son billet “Unix manual pages for PHP functions”

Il s’agit d’installer les fameuses man page UNIX pour toutes les fonctions PHP.

A quoi cela peut il bien servir ?

Tout d’abord, à avoir de la documentation en ligne de commande, sans avoir à lancer un navigateur Web. Très utile quand la connexion internet est limitée ou lorsqu’on est en train de modifier du code sur un serveur de production (ce qui bien sûr ne devrait jamais arriver).

Mais surtout, l’installation de ces pages permet d’obtenir la documentation des fonctions PHP directement dans le code PHP, dans VI, mon éditeur préféré et probablement celui de tous les vieux développeurs barbus.

Let’s rock !

Installer le package pman depuis PEAR (je ne vais pas détailler ici comment installer ou configurer PEAR) :

$ pear install doc.php.net/pman

Si vous utilisez une vielle version de PEAR, il faut ajouter doc.php.net aux repositories :

$ pear channel-discover doc.php.net

puis relancer pear install

C’est fait !

Normalement, en tapant :

$ pman strstr

On obtient une man page UNIX documentant de façon extrêmement complète la fonction PHP strstr

Enfin, pour intégrer cela dans notre éditeur préféré, ajoutez juste la ligne :

set keywordprg=pman

dans le fichier .vimrc de votre profile.

Ouvrez un fichier PHP, positionnez le curseur sur une fonction PHP et appuyez sur “K”.

Magie…. une man page apparaît avec le descriptif de la fonction pointée.

Evidemment, comparé aux nouveaux IDE surpuissants, ce n’est pas grand chose. C’est un peu comme trouver un émulateur SuperNes pour Linux, ou utiliser Lynx pour naviguer sur le web. En tout cas, ça me rappelle qu’en informatique, on peut faire de belle chose avec de petits moyens.

A bon entendeur !

Oauth est un protocole créé en 2007. Il permet aux applications web, mobiles ou de bureaux, d’accéder à des services distants via des API, sans demander aux utilisateurs d’exposer leurs identifiant / mot de passe.

Oauth est largement utilisé par Google, Twitter ou encore LinkedIn pour ne citer qu’eux.

Auparavant, l’API twitter n’est disponible qu’en passant le twitterId et le mot de passe de l’utilisateur dans l’URL du service. Cela supposait donc que les applications utilisant l’API gardaient ces informations et pouvaient donc les utiliser à mauvais escient.

Dans ce billet, j’essaye d’expliquer comment consommer un service Oauth, avec un des composants PHP du Zend Framework.

Read the rest of this entry »

On utilise souvent les jobs CRON pour effectuer des traitements lourds en tâches de fond : calcul de statistiques, conversion d’image, envoi de mail etc…

L’inconvénient de CRON par rapport à d’autres systèmes de jobs intégrés dans les plateformes J2EE ou .NET, c’est qu’il ne gère pas le “chevauchement” des tâches.

Je m’explique : imaginons une tâche lancée toutes les heures et qui prend 30 min pour traiter un 1Go de données. Si la taille des données augmente, ce que nous souhaitons tous pour nos applications, le traitement s’effectuera peut être en plus d’une heure. Que se passe t-il alors si la tâche est relancée alors que l’occurrence précédente n’est pas terminée ? Au mieux, les données peuvent être corrompues, au pire, la plateforme peut tomber sous le poids des traitements.

Voici donc une façon de gérer les “lock” en PHP, afin de garantir qu’une occurrence de tâche CRON s’exécute si et seulement si la l’occurrence précédente est terminée.

Read the rest of this entry »