1. 3
  1. 1

    This is weird because it’s talking about two different things. Floating point values are imprecise, not too precise.

    I’d also argue against a date object being wrong for too much precision. He’s asking to compare it against a particular time. If you think it should have an implicit 23:59 in it, that breaks the other comparison for start time, and is way less sensible.

    1. 2

      Re: dates: well, you’re correct in the javascript model. But he seems to be imagining a model of dates and times where you have a “Date” concept and a separate “DateTime” concept. Then if I had start = Date{2016-10-01}, end = Date{2016-11-08}, time = DateTime{2016-11-08 08:00}, I’d expect time >= start to be true, and time <= end to be true as well, because when I compare a DateTime to a Date, they are “equal” if the Date part matches. In this model there’s no “implicit 23:59” involved.

      Dates and times are tricky, but I would find that model useful, since date inclusion like this is a common task.

      1. 4

        That model does not work well in practice, because of timezones.

        “December 15th, 2016” is a date on the calendar, “Dec. 15th, 2016, 4 PM” is a point on a timeline, but “Dec. 15th, 2016, 8PM UTC” is what people usually want for things like timestamps.

        The question' “Dec. 15th, 2016” contains the event that happened at “Dec. 15th, 2016 8PM UTC”‘ has many answers, dependent on context. If the context is “Dec. 15th, but in Japan”, the naive answer is no. If the context is “in UK”, the answer is yes. if the context is “In a timezone set by the user”, the answer depends.

        If you allow comparisons/operations between dates and datetimes you end up in situations where suddenly the difference between two dates isn’t 1 day, but 23 hours, so date_difference.days == 0 (happens in billing code if you naively use datetimes to track when people signed up to things, or to track plan validity intervals).

        The best (read: one where you have to be the most explicit) model is one where dates and datetimes are incomparable, and you instead have to explicitly convert “correctly”.

        1. 1

          That’s a good way to break the transitive property.

          start < time == true
          time < end == true
          start < end == false
          1. 2

            There is no meaningful < operator between a date and a date+time; a date is a range, and a time is a snapshot.

            You could compare the start of the date with a date+time, or the end.

      2. 1

        Solution: Use half-open ranges. The advantages of half-open ranges are well-known:

        (0) Adjacent ranges share an endpoint: [a,b) and [b,c).

        (1) The size of a range is the difference of its endpoints: b-a.

        (2) Iterating a half-open range is very simple:

        i := a
        while i <> b:
            i := next(i)