2

How does one conceptually manage date-ranges, specifically the ending-date when there is a time-component involved (as in JavaScripts Date, C# DateTime, MS-SQLs datetime2).

For example, humans saying "from 01-07-2017 to 10-07-2017" would give the mental model of both dates being inclusive (at least in most cases in my culture). But how would i store that last date, while being able to perform arithmetic correctly on it, and storing a "data-correct" value?

Possible canidates:

  • 11-07-2017 00:00:00
  • 10-07-2017 23:59:59
  • 10-07-2017 00:00:00

And "where" would my abstraction of this be, optimally?

  • Maybe you could ask at UX stackexchange. They are more experienced about what user assumptions and expectations are. – Euphoric Aug 21 '17 at 8:10
  • At my organization, we always store the beginning of the first day and the beginning of the last day (which would be 01-07-2017 00:00:00 and 10-07-2017 00:00:00 in your example). This frequently results in bugs when developers do a comparison incorrectly, and I've always thought it's kind of a silly way of doing things. – Tanner Swett Aug 22 '17 at 19:22
  • @TannerSwett so how would you rather do it? Change the point stored to something else? Abstract new comparison methods that take this into account? – BobbyTables Aug 23 '17 at 6:30
  • Store the end of the last day (11-07-2017 00:00:00) instead of the beginning. – Tanner Swett Aug 23 '17 at 13:40
4

If possible, do not to use a data type with a higher precision than "one day" if you do not need a better precision. If your database, or your programming language only provides you with a data type for date & time combined, then set the time part to zero when mapping it to "date only", anything else will make things obfuscated for the maintenance programmer which comes after you.

That will still leave open if one should store

  • the exact end date

  • the "real" end date + 1 day

for the end date of an interval.

Date arithmetics can be implemented correctly with both approaches, there are pros and cons for both sides (this is quite similar to some programming languages defining array bounds for a[n] from 0 to n-1, whilst other languages provide "1 to n" semantics). The obvious "pro" argument for the first is, the semantics is more alike to what most people expect, as you already wrote, so it is probably less error prone in its interpretation.

The argument for the second approach is, to calculate the number of days in the interval between start and end date, one can just build the "difference" between both dates, without the need for adding 1 afterwards. Same holds when one gets a point p in time where p is a "date&time" variable, and the task is to check if p is in the range from start_date to end_date, one will also save an addition of one day here (no less, no more).

However, both representions have a certain risk of introducing off-by-one errors, that is quite inevitable. So there is IMHO no "better" or "optimal" solution, choose the one which serves you best, which fits better to your overall requirements, or to the existing system. If you still can't make a decision, throw a dice. However, if you have more than one place in your application dealing with date intervals, I would recommend to be consistent in how you implement it.

  • thanks for shedding light on different aspects of the question – BobbyTables Aug 22 '17 at 8:41
1

My preferred approach is to use '11-07-2017 00:00:00' ie the start of the next day.

This enables you to to correct arithmetic, such as does this datetime fall on the day without the problem of the 60th second using x >= date && x < date2

It also works well for the end of months, years etc

However, you are correct in that it is not a very human way of presenting the information when it is say a checkout date for a hotel.

In those cases I use the presentation layer to make it clear. Rather than simply stating from and to dates, I add extra wording, "checking out on the morning of" or whatever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.