Heure GMT / UTC (non locale) au format Unix

J’utilise JavaScript et j’essaie d’obtenir le temps GMT + 0 / UTC + 0 (autre que le temps Zulu) au format Unix.

J’ai réussi à obtenir mon heure locale au format Unix comme ceci:

var datetime = new Date() var unixtime = Math.floor(Number(datetime/1000));

mais quand j’essaie de faire la même chose avec l’heure UTC …

 var datetime = new Date() var year = datetime.getUTCFullYear() var month = datetime.getUTCMonth() var day = datetime.getUTCDate() var hours = datetime.getUTCHours() var minutes = datetime.getUTCMinutes() var seconds = datetime.getUTCSeconds() var unixtime = (Date.UTC(year,month,day,hours,minutes,seconds,00)/1000);

il échoue. Je reçois simplement mon heure locale au format Unix.

Vous pouvez l’exécuter en direct ici: http://jsfiddle.net/wC8XH/1/ (Aussi sur pastebin: http://pastebin.com/uDD5zUah )

Voici un exemple de sortie:

 2012-01-30 23:15:19 = 1327958119 2012-01-30 21:15:19 = 1327958119

Faire:

 date -d "2012-01-30 21:15:19" +%s

sous Linux me donne 1327950919, pas 1327958119. La différence est de 7200 secondes, soit 2 heures, ce qui est mon fuseau horaire (+0200).

Donc, je peux obtenir l’heure UTC + 0 si je le veux simplement dans un format lisible par l’homme mais quand je demande Date.UTC pour le convertir au format Unix, il choisit plutôt de convertir mon heure locale.

Est-ce que je manque quelque chose?

Oui, vous avez le problème à l’envers.

Javascript indique toujours le nombre de secondes au format “Unix” en UTC ou GMT. Parce qu’Unix fonctionne toujours en interne en UTC ou GMT. Cela n’a pas de sens de parler du «temps Unix» sans que ce soit du temps universel coordonné.

Donc, vos deux fragments de code Javascript trouvent la même réponse correcte (Quelle est l’heure “unix”?) D’une manière simple et d’une manière très compliquée, c’est pourquoi ils donnent le même résultat.

… et la commande de date est sensible aux parameters régionaux. Dans votre région, vous avez un décalage de 2 heures, ce qui suppose que votre chaîne de date comporte un décalage de 2 heures. Vous pouvez lui dire de ne pas se comporter de la sorte en utilisant le drapeau -u, ce qui signifie que vos chaînes sont à l’heure UTC.

Voici quelques exemples: en définissant la variable d’environnement TZ, le fuseau horaire apparent des chaînes fournies est modifié (les valeurs de TZ affichées correspondent à un fichier de fuseau horaire Unix commun, les noms disponibles sur votre système spécifique peuvent varier).

 $ TZ="America/New_York" date -d "2012-01-30 21:15:19" +%s 1327976119 $ TZ="Europe/Paris" date -d "2012-01-30 21:15:19" +%s 1327954519 $ date -u -d "2012-01-30 21:15:19" +%s 1327958119

Tout d’abord, comme l’ a déjà indiqué @tialaramex , les deux extraits de code JavaScript sont corrects, vous devriez donc préférer le plus court.

Le problème est avec la commande de date Linux. Lorsque vous passez une date, il est interprété dans votre fuseau horaire actuel, pas en UTC! Regardez:

 $ date -d "2012-01-30 21:15:19" +%s 1327954519 $ scala scala> new java.util.Date(1327954519 * 1000L) res0: java.util.Date = Mon Jan 30 21:15:19 CET 2012

Je vis au CET, notez que la date sortie est différente de la vôtre.

MISE À JOUR: suivant la grande suggestion de @derobert ci-dessous dans les commentaires, vous pouvez spécifier le fuseau horaire explicitement lorsque vous appelez la date :

 $ date -d "2012-01-30 21:15:19+0000" +%s 1327958119 $ scala scala> new java.util.Date(1327958119 * 1000L) res0: java.util.Date = Mon Jan 30 22:15:19 CET 2012

21h15 dans l’UTC est 22h15, tout est en ordre.