Come gestisci gli intervalli di date, quando i tipi di dati includono l'ora?

Se possibile, non utilizzare un tipo di dati con una precisione maggiore di "un giorno" se non hai bisogno di una precisione migliore. Se il tuo database, o il tuo linguaggio di programmazione ti fornisce solo un tipo di dati per data e amp; tempo combinato, quindi imposta la parte del tempo su zero quando si esegue il mapping su "date only", qualsiasi altra cosa renderà le cose offuscate per il programmatore di manutenzione che viene dopo di te.

Rimane aperto se è necessario archiviare

• la data di fine esatta

• la data di fine "reale" + 1 giorno

per la data di fine di un intervallo.

L'aritmetica delle date può essere implementata correttamente con entrambi gli approcci, ci sono pro e contro per entrambi i lati (questo è abbastanza simile ad alcuni linguaggi di programmazione che definiscono i limiti degli array per a[n] da 0 a n-1, mentre altri linguaggi forniscono "1 alla "semantica"). L'ovvio argomento "pro" per il primo è che la semantica è più simile a ciò che la maggior parte della gente si aspetta, come hai già scritto, quindi è probabilmente meno incline alla sua interpretazione.

L'argomento del secondo approccio è, per calcolare il numero di giorni nell'intervallo tra la data di inizio e di fine, uno può semplicemente costruire la "differenza" tra le due date, senza la necessità di aggiungere 1 successivamente. Lo stesso vale quando si ottiene un punto p nel tempo in cui p è una variabile "data e ora", e l'attività è di verificare se p è nell'intervallo da start_date a end_date , uno sarà salva anche un'aggiunta di un giorno qui (non di meno, non di più).

Tuttavia, entrambe le rappresentazioni hanno un certo rischio di introdurre errori off-by-one, il che è piuttosto inevitabile. Quindi non c'è IMHO soluzione "migliore" o "ottimale", scegliere quello che ti serve meglio, che si adatta meglio alle vostre esigenze generali, o al sistema esistente. Se ancora non riesci a prendere una decisione, lancia un dado. Tuttavia, se hai più di un posto nella tua applicazione che si occupa degli intervalli di date, ti consiglio di essere coerente nel modo in cui lo implementa.

Il mio approccio preferito è utilizzare '11 -07-2017 00:00:00 ', ovvero l'inizio del giorno successivo.

Questo ti permette di correggere l'aritmetica, come fa questo datetime cadere nel giorno senza il problema del 60esimo secondo usando x >= date && x < date2

Funziona bene anche per la fine di mesi, anni ecc.

Tuttavia, hai ragione nel dire che non è un modo molto umano di presentare le informazioni quando si dice una data di check-out per un hotel.

In quei casi, uso il livello di presentazione per renderlo chiaro. Invece di limitarmi a indicare date e date, aggiungo parole extra, "check out on the morning of" o qualsiasi altra cosa.