Nel calcolare quanti giorni tra 2 date, dovresti includere entrambe le date nel conteggio, o nessuna delle due, o 1?

Innanzitutto cosa avrebbe senso nella tua domanda se entrambe le date fossero lo stesso giorno? A mio parere, la risposta ovvia è 0 e se questa è la tua risposta, allora la conclusione logica è quella di mappare le date che differiscono di un giorno in 1 e non in 2. Se mappi date che differiscono di un giorno in 2, allora hai un intervallo e non c'è modo di mappare le date che non coincidono con 1. Da una prospettiva matematica le cose si sentono più coerenti se non ci sono spazi vuoti.

Risponderei 1 perché sono a un giorno di distanza. Non c'è una risposta giusta a questo però. Dipende dai requisiti per ciò che vuoi ottenere.

Penso che sia una questione di terminologia e contesto.

Se tra i due giorni non sono compresi i limiti, i giorni tra le due date saranno 0. Ove ciò sia necessario.

Differenza di data, ovvero quanti giorni ho bisogno di aggiungere alla data di inizio per raggiungere la data di fine: 1.

O un intervallo di date, compresi i limiti, ad es. quanti giorni di ferie ho da un inizio a una data di fine? Qui la risposta è 2.

Penso che il punto cruciale del dilemma sia che hai chiamato l'operazione "calcolando quanti giorni tra due date". Chiaramente ci sono zero giorni tra il 3/1/12 e il 3/2/12, ma questo probabilmente significa che hai sbagliato il calcolo del nome e non il calcolo sbagliato.

L'aritmetica delle date è notoriamente complicata a causa di tutte le eccezioni, quindi devi essere rigoroso nel definire le tue esigenze. Ad esempio, in cosa si traduce "adesso meno un giorno"? Si potrebbe dire che ciò significa che è durata 24 ore fa, ma penso che sarebbe sbagliato nella maggior parte delle applicazioni. È vero, la maggior parte dei giorni ha 24 ore, ma con l'ora legale un giorno ha 23 ore e un giorno ha 25 ore. Ringrazio se è mezzogiorno di domenica, ma ora meno un giorno significa mezzogiorno di sabato, indipendentemente da quante ore fa. Potrei andare avanti con secondi bisestili e tutti i problemi che portano, oltre a garantire che tutte le identità e le proprietà aritmetiche siano valide, ma tutto questo è probabilmente più lavoro di quanto tu voglia fare.

Generalmente, quando si fa una data del calendario, le persone aritmetiche sono interessate alla "differenza tra le date". Puoi visualizzarlo immaginando un calendario cartaceo con le date stampate su di esso e mettendo una moneta o una pietra o un altro indicatore sulla data di inizio. Se ti è consentito solo spostare il marcatore alla data immediatamente successiva, quanti spostamenti ti porteranno per arrivare alla data finale? Questa è la differenza tra le due date in giorni.

Un'altra considerazione pratica, tuttavia, è se la tua applicazione include realmente la data di fine. È tipico per i contratti di assicurazione, ad esempio, non includere la data di fine. Le norme scadono alle 00:01 della data di fine. Se acquisti una politica che scade domani, va bene per meno di un giorno. D'altra parte, in California, un avviso di sfratto di "3 giorni per pagare l'affitto o la cessazione" ti dà più di 3 giorni per uscire. Hai tempo fino alla fine del terzo giorno lavorativo dopo che l'avviso è stato notificato per pagare l'affitto. Quindi il mercoledì + 3 giorni è in realtà il lunedì a meno che il lunedì non sia un giorno festivo, nel qual caso è martedì e in entrambi i casi si ottiene l'intero giorno finale, quindi un proprietario non può procedere fino ad oggi > Mercoledì + 3 giorni, martedì o mercoledì. Quindi non è un calcolo semplice.

La buona notizia è che, poiché si presenta così spesso, ci sono librerie che puoi usare per fare i calcoli e le situazioni della vita reale hanno ragionevolmente ben definito come vogliono fare i calcoli della data per chiarire solo questi tipi di confusione.

Quindi hai davvero bisogno di fare i compiti e specificare correttamente l'intervallo di cui stai parlando.

In definitiva, la risposta corretta a questo è qualunque siano i requisiti aziendali.

Tuttavia, quando si ha a che fare con date e intervalli di tempo tra una data e l'altra, un modo generico di considerarlo per supporre che qualsiasi data che è espressa esclusivamente come una data (cioè senza una porzione temporale) è implicitamente aggiungi 00:00 alla fine della data (mezzanotte).

Ora, calcola quanti minuti di differenza c'è tra le due date / ore. Quindi, usando il tuo esempio (e sto assumendo il formato di data USA qui), quanti minuti devi aggiungere, uno alla volta, a 2/1/2012 00:00 prima di raggiungere 3/1/2012 00:00 ?

Dopo averlo fatto, converti i tuoi minuti in ore, quindi in giorno (dividi per 60, quindi dividi il risultato per 24) e avrai il tuo numero di giorni tra le due date.

Usando questo, si scopre che c'è 1 giorno tra 2/1/2012 00:00 e 3/1/2012 00:00 che sembra essere sia logico che in accordo con il pensiero generale della maggior parte delle persone qui e coloro che progettano funzioni ben usate in quest'area (es. Java java.util.Date o .NET System.DateTime ecc.)

Devi considerare il contesto, se il mio programma di lavoro è dal lunedì al venerdì il mio capo sarà un po 'scontento se mi presenterò solo per 4 giorni.

Questo perché in questo contesto, il lunedì non è valido solo per lunedì ma per lunedì 8:30 e venerdì per venerdì 17:00.

Il numero di giorni ND tra una data D1 e un'altra data D2 è tale che:

ND = D2 - D1

o

D1 + ND = D2

Dipende molto dal contesto, ma a mio parere la risposta ovvia è includere 1 delle date nel conteggio.

Supponiamo che tu non conti nessuno dei due. E supponiamo anche che ci sia un'applicazione che usa il tuo algoritmo per determinare la differenza di 2 date digitate dall'utente. In questo caso, la differenza tra il 3/1/2012 e il 3/2/2012 è 0. È quindi ok per l'utente assumere che le 2 date siano uguali? Perché è ciò che 0 suggerisce: nessuna differenza tra loro - > > sono uguali. Probabilmente è sbagliato ...

Supponiamo quindi di contare entrambi. In questo caso, la differenza non sarà mai inferiore a 2. Ci sono 2 giorni tra il 3/1/2012 e il 3/2/2012? Certamente no. Che dire tra il 3/1/2012 e il 3/1/2012? Ancora: no.

Dato che hai solo date come input e nessun tempo, farei l'algoritmo in questo modo:

• se la data 1 è uguale alla data 2, la risposta è 0
• se la data 1 è diversa dalla data 2, la risposta è il numero di giorni tra di loro + 1 (il "+ 1" significa che una delle date è inclusa nel conteggio).

Come ho detto all'inizio: questo dipende in ultima analisi dalle tue esigenze aziendali.

Entrambe le date, perché è ciò che gli utenti si aspettano (nella maggior parte dei casi)

Ho lavorato su alcuni progetti che dovevano funzionare con la logica che circonda le date e la scadenza delle entità. E ci sono alcune insidie.

La natura di queste trappole è che ciò che ha senso per un programmatore non è necessariamente ciò che ha senso per le persone che usano l'applicazione.

Le persone nel business normalmente dicono cose del genere, questa cosa è attiva dal 1. al 31. di luglio. Ora, ciò che intendono è che entrambe le date sono incluse, cioè dovrebbe essere attiva per 31 giorni, non 30. Ma ciò sfugge alle normali regole aritmetiche.

Quindi, se si pone la domanda dal punto di vista degli utenti finali, nella mia esperienza la risposta dovrebbe essere che è necessario includere entrambe le date quando si calcola il numero di giorni.

Alcuni esempi della mia esperienza lavorativa:

Ho lavorato alla creazione di una bacheca online e abbiamo avuto molti problemi con le date di fine per alcuni tipi di entità (scadenza per un lavoro, una sottoscrizione, ecc.). Questi sarebbero specificati come l'ultimo giorno in cui questa entità era ancora valida, che è ciò che è stato memorizzato nel database. Ma ciò che avrebbe avuto senso nel codice sarebbe stato avere l'ora esatta in cui l'entità avrebbe cambiato stato, cioè alle 00:00 della seguente data. Ciò porta a una logica di dominio molto complessa.

A un certo punto, ho rifattorizzato l'intero sistema, aggiungendo un giorno a ogni EndDate nel database, quindi spostato la logica al livello di presentazione, specificando che la data effettiva presentata all'utente dovrebbe essere il giorno che precede quello nel database. Ciò ha portato a una logica di dominio molto più pulita per quanto riguarda la scadenza degli articoli.

Quando ho realizzato il prossimo progetto con cui era importante la data / la logica di scadenza dell'entità, ho creato un tipo di dati Data specifico per racchiudere queste regole, inclusi gli operatori di confronto di overload con la build in DateTime classe, operatori aritmetici, ecc. Ciò ha portato a un codice ancora più semplice, poiché rispecchiava molto meglio il modello di dominio e sono stati rimossi i requisiti per sottrarre il livello di un giorno da tutti i giorni di fine, rimuovendo anche il rischio che qualcuno dimenticasse di implementarlo.