My recommendation is to convert to UTC as early as possible, stay in UTC as long as possible, and convert to local time as late as possible — preferably in JavaScript on the client.— Sam Ruby, Dealing With Dates
This was a response to Simon Willison that was complaining about the Python’s timezone management which isn’t trivial. And definitively agree with him saying that you should work in UTC (Coordinated Universal Time) as early and as long as possible. Store your datetime in UTC. If you deal with that manually you’re wrong. I’ve seen too many +1 and +2 to fix hours. Half of the time you’ll forget that it’s the summer time and not the standard time and do a mistake. i.e. SQLite3 handles that pretty nicely (the example is in the French part this time, sorry).
I realized yesterday night that a Facebook application (Friends for sale) — I’m spending too much time in — is using this philosophy, writing the “1 hour ago” via JavaScript. Filling a span that contains the info into text.
<span class="date" id="app7019261521_time_139914419"> </span>
into:
<span class="date" id="app7019261521_time_139914419"> 40 minutes ago </span>
It’s badly done (from an accessibility point of view but is really brilliant. This means you can cache this page for ever[1] and the difference will keep updating. Twitter that faced a lot of performance issues isn’t doing that and keeps calculating that for you (which is nice but time consuming). Even when they plans a maintenance and gives you the time in PST (Pacific Standard Time, GMT-8) which means quite nothing for the rest of the world.
So I built a JavaScript tool that will replace every datetime pattern (straight from the microformats planet) into a difference. What I would recommend — even if we now that microformats aren’t good from an accessibility point of view — is to fill the abbr with a human readable date time. So if it’s 50 years in the past, it would be preferable to have the real date time. And it have be a progressive enhancement, not an information for JavaScript enabled browsers/users only.
There is a demo: test it, grab it, hack it, play with it.
If it’s easy to translate an absolute time to a relative one, it’s also possible to express one time in your timezone, i.e. from PST (San Fransisco) to EST (New York City). We usually don’t have that kind of issue in Europe because there are 3 timezones basically (WET, CET and EET and in Summer: WEST, CEST and EEST) and different languages are spoken in each places. For example, CNN shows explicitly the timezone that was choosen, ET/EST, BBC shows GMT and Google News displays only the date and not the hour. Even if you translate the timezone into the user’s one, keep displaying it or you’ll break its habits and the experience built over the years.
1) this blog post is a static file (I swear).
Dans un post datant de début septembre passé, Sam Ruby montrait la relative simplicité de gérer le fuseau horaire d’un champ date répondant ainsi à une complainte de Simon Willison. Et ce que j’ai gardé en mémoire de ce post là est son conseil de travailler avec des dates en UTC (Temps Universel Coordonné), ayant remplacé GMT en 1972, et est donc insensible au passage à l’heure d’été. Son conseil se résume par dire convertissez le plus tôt possible au format UTC et localisez ensuite cette information le plus tardivement possible dans le fuseau horaire de l’utilisateur, préférablement en JavaScript côté client.
Côté stockage, par exemple, SQLite le gère très bien de manière non douloureuse et élégante:
CREATE TABLE foo ( id INTEGER PRIMARY KEY, created REAL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO foo (id) VALUES (NULL); SELECT *, datetime(created, "localtime") FROM foo;
J’ai réalisé hier soir qu’une des applications qui me fait perdre le plus de temps sur le bien nommé Facebook: Friends for sale, va calculer les différenciels de temps genre: “il y a 2 heures”, “il y a 3 jours” côté client, en JavaScript, ce que Twitter ne fait pas (pour prendre un autre exemple). Ceci à l’énorme avantage d’éviter tout calcul côté serveur et permettre de faire du cache ad eternam. La page ayant l’information du quand absolu et, dynamiquement, cette information est rendue utilisable dans un format plus approprié, dans ce cas relatif.
Malheureusement si l’idée est bonne elle me semble un peu maladroitement réalisée car en désactivant JavaScript plus rien de n’affiche. À mon avis, il y a de quoi faire un peu mieux et en restant plus proche d’éléments existant en lorgnant du côté des microformats. En effet, un champ date va être représenté selon de datetime pattern qui place l’information absolue dans l’attribut titre (title) d’une abbréviation (abbr). Bien que contestée du point de vue accessibilité — cette information là n’étant absolument pas destinée à être lue par un humain/lecteur d’écran — s’inscrire dans un (presque) standard de facto est séduisant. À l’attaque, avec en entrée :
<abbr title="2008-01-20T20:00:00+01:00"> le dimanche 20 janvier à 20h00 (CET) </abbr>
qui va être ré-exprimé ensuite, par exemple, comme suit :
<abbr title="2008-01-20T20:00:00+01:00"> il y a environ 3h </abbr>
tenant compte de l’heure courante.
Il est imaginable de n’adapter que l’heure à votre fuseau horaire, en admettant que vous viviez à New York City (EST, GMT-5), qui irait traduire 20h00 en 14h00. Je suis d’avis que même en effectuant une traduction de l’heure à celle de l’utilisateur, il serait casser ses habitudes et l’expérience qu’il a construit au fil du temps que de la masquer. Si un jour, CNN affiche les heures de publication à l’heure de Paris (Bruxcelles, Berne, Berlin, Rome, ...) au lieu de EST, il est certain que je me sentirait plus à l’aise à ne pas avoir à traduire cette information là de moi-même.
Sinon un petit exemple de ce que ça peut donner.
