Lors de l'écriture d'une application web, il est logique de stocker (côté serveur) toutes les dates dans la base de données sous forme d'horodatage UTC.
J’ai été étonné de constater qu’on ne pouvait pas faire grand-chose en termes de manipulation des fuseaux horaires en JavaScript.
J'ai étendu un peu l'objet Date. Cette fonction a-t-elle un sens ? En gros, chaque fois que j'envoie quelque chose au serveur, il s'agit d'un horodatage formaté avec cette fonction...
Voyez-vous des problèmes majeurs ici ? Ou peut-être une solution sous un angle différent ?
Date.prototype.getUTCTime = function(){
return new Date(
this.getUTCFullYear(),
this.getUTCMonth(),
this.getUTCDate(),
this.getUTCHours(),
this.getUTCMinutes(),
this.getUTCSeconds()
).getTime();
}
Ça me semble juste un peu alambiqué. Et je ne suis pas non plus très sûr de la performance.
Les dates construites de cette manière utilisent le fuseau horaire local, ce qui rend la date construite incorrecte. Pour définir le fuseau horaire d'un objet date donné, il faut le construire à partir d'une chaîne de date qui inclut le fuseau horaire. (J'ai eu des problèmes pour que cela fonctionne dans un ancien navigateur Android).
Notez que getTime()
renvoie des millisecondes, et non des secondes.
Pour un timestamp UTC/Unix, ce qui suit devrait suffire:
Math.floor((new Date()).getTime() / 1000)
Le décalage du fuseau horaire actuel sera pris en compte dans le résultat. Pour une représentation sous forme de chaîne, la réponse de David Ellis' ; fonctionne.
Pour clarifier:
new Date(Y, M, D, h, m, s)
Cette entrée est traitée comme une heure locale. Si l'on passe l'heure UTC, les résultats seront différents. Observez (je suis en ce moment à GMT +02:00, et il est 07:50):
> var d1 = new Date();
> d1.toUTCString();
"Sun, 18 Mar 2012 05:50:34 GMT" // two hours less than my local time
> Math.floor(d1.getTime()/ 1000)
1332049834
> var d2 = new Date( d1.getUTCFullYear(), d1.getUTCMonth(), d1.getUTCDate(), d1.getUTCHours(), d1.getUTCMinutes(), d1.getUTCSeconds() );
> d2.toUTCString();
"Sun, 18 Mar 2012 03:50:34 GMT" // four hours less than my local time, and two hours less than the original time - because my GMT+2 input was interpreted as GMT+0!
> Math.floor(d2.getTime()/ 1000)
1332042634
Notez également que getUTCDate()
ne peut pas être substitué à getUTCDay()
. En effet, getUTCDate()
renvoie le jour du mois ; alors que getUTCDay()
renvoie le jour de la semaine.
Vous pouvez également le faire en utilisant getTimezoneOffset et getTime,
x = new Date()
var UTCseconds = (x.getTime() + x.getTimezoneOffset()*60*1000)/1000;
console.log("UTCseconds" ;, UTCseconds)
En fait, je pense que les valeurs de date en js sont bien meilleures que les objets DateTime de C#. Les objets DateTime de C# ont une propriété Kind, mais pas de fuseau horaire sous-jacent strict en tant que tel, et les conversions de fuseau horaire sont difficiles à suivre si vous convertissez entre deux heures non UTC et non locales. En js, toutes les valeurs de date ont une valeur UTC sous-jacente qui est transmise et connue indépendamment des conversions de décalage ou de fuseau horaire que vous faites. Ma plus grande plainte à propos de l'objet Date est la quantité de comportements non définis que les implémenteurs des navigateurs ont choisi d'inclure, ce qui peut dérouter les personnes qui s'attaquent aux dates en js par essais et erreurs plutôt qu'en lisant la spécification. L'utilisation de quelque chose comme iso8601.js résout ce comportement variable en définissant une implémentation unique de l'objet Date.
Par défaut, la spécification indique que vous pouvez créer des dates avec un format de date ISO 8601 étendu tel que
var someDate = new Date('2010-12-12T12:00Z');
Vous pouvez donc déduire l'heure UTC exacte de cette façon.
Lorsque vous voulez renvoyer la valeur de la date au serveur, vous devez appeler
someDate.toISOString();
ou si vous préférez travailler avec un horodatage en millisecondes (nombre de millisecondes à partir du 1er janvier 1970 UTC)
someDate.getTime();
La norme ISO 8601 est une norme. Vous ne pouvez pas vous tromper sur la signification d'une chaîne de date si vous incluez le décalage de date. En tant que développeur, cela signifie que vous n'avez jamais à vous occuper des conversions d'heure locale. Les valeurs d'heure locale existent uniquement pour le bénéfice de l'utilisateur, et les valeurs de date s'affichent par défaut dans leur heure locale. Toutes les manipulations de l'heure locale vous permettent d'afficher quelque chose de sensé pour l'utilisateur et de convertir des chaînes de caractères à partir des entrées de l'utilisateur. La bonne pratique consiste à convertir en UTC dès que possible, et l'objet Date de js rend cette opération assez triviale.
L'inconvénient est qu'il n'y a pas beaucoup de possibilités de forcer le fuseau horaire ou la locale du client (à ma connaissance), ce qui peut être gênant pour les paramètres spécifiques au site web, mais je suppose que le raisonnement derrière cela est qu'il s'agit d'une configuration utilisateur à laquelle il ne faut pas toucher.
Donc, en résumé, la raison pour laquelle il n'y a pas beaucoup de support natif pour la manipulation des fuseaux horaires est que vous ne voulez tout simplement pas le faire.