Au moment d'écrire ces lignes, une seule des autres réponses gère correctement les transitions DST (heure d'été). Voici les résultats sur un système situé en Californie:
1/1/2013- 3/10/2013- 11/3/2013-
User Formula 2/1/2013 3/11/2013 11/4/2013 Result
--------- --------------------------- -------- --------- --------- ---------
Miles (d2 - d1) / N 31 0.9583333 1.0416666 Incorrect
some Math.floor((d2 - d1) / N) 31 0 1 Incorrect
fuentesjr Math.round((d2 - d1) / N) 31 1 1 Correct
toloco Math.ceiling((d2 - d1) / N) 31 1 2 Incorrect
N = 86400000
Bien que Math.round
renvoie les résultats corrects, je pense que c'est un peu maladroit. Au lieu de cela, en prenant explicitement en compte les modifications du décalage UTC au début ou à la fin de l'heure d'été, nous pouvons utiliser l'arithmétique exacte:
function treatAsUTC(date) {
var result = new Date(date);
result.setMinutes(result.getMinutes() - result.getTimezoneOffset());
return result;
}
function daysBetween(startDate, endDate) {
var millisecondsPerDay = 24 * 60 * 60 * 1000;
return (treatAsUTC(endDate) - treatAsUTC(startDate)) / millisecondsPerDay;
}
alert(daysBetween($('#first').val(), $('#second').val()));
Explication
Les calculs de date JavaScript sont délicats car les Date
objets stockent les heures en interne en UTC, pas l'heure locale. Par exemple, 3/10/2013 12:00 AM heure normale du Pacifique (UTC-08: 00) est stockée sous la forme 3/10/2013 8:00 AM UTC et 3/11/2013 12:00 AM Pacific Daylight Time ( UTC-07: 00) est stocké sous la forme 3/11/2013 7:00 AM UTC. Ce jour-là, de minuit à minuit, l'heure locale n'est que de 23 heures en UTC!
Bien qu'une journée dans l'heure locale puisse avoir plus ou moins de 24 heures, une journée en UTC est toujours exactement 24 heures. 1 La daysBetween
méthode illustrée ci-dessus tire parti de ce fait en appelant d'abord treatAsUTC
pour ajuster les deux heures locales à minuit UTC, avant de soustraire et de diviser.
1. JavaScript ignore les secondes intercalaires.