De cette écriture, un seul des autres réponses gère correctement l'heure d'été (daylight saving time) des transitions. Voici les résultats sur un système qui se trouve 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 qu' Math.round
renvoie des résultats corrects, je pense que c'est un peu maladroit. Au lieu de cela, explicitement, de la comptabilité pour la modification du décalage UTC lorsque l'heure d'été commence ou se termine, nous pouvons utiliser exacte de l'arithmétique:
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
JavaScript date de calculs sont difficiles parce qu' Date
objets magasin de temps à l'interne en UTC, pas de temps local. Par exemple, 3/10/2013 12:00 AM, Heure normale du Pacifique (UTC-08:00) est stockée en tant que 3/10/2013 8:00 UTC, et 3/11/2013 12:00 AM, Heure Avancée du Pacifique (UTC-07:00) est stockée en tant que 3/11/2013 7:00 h UTC. En ce jour, de minuit à minuit, heure locale, il est seulement de 23 heures à l'UTC!
Mais un jour dans l'heure locale peut avoir plus ou moins de 24 heures, un jour à l'UTC est toujours exactement 24 heures.1 L' daysBetween
méthode indiquée ci-dessus prend le parti de ce fait en première convocation, treatAsUTC
à ajuster l'heure locale à minuit UTC, avant soustraction et la division.
1. JavaScript ignore les secondes intercalaires.