4 ms·
I think you misunderstood the author's point: time periods aren't explicitly represented as (Date: start, Date: end). Instead they're a set of dates. The time p
by jxf 6y ago
I think you misunderstood the author's point: time periods aren't explicitly represented as (Date: start, Date: end). Instead they're a set of dates. The time periods are then implied by the set, making "end date before start date" impossible.
- VBprogrammer 6y agoIt also deals with the problem of the bounds on the ranges (open-closed, open-open etc) implicitly in a way which is harder to mess up. One complication it's potentially missing is exactly who's days we are talking about i.e. is it days starting in GMT or UTC or EST or whatever the 'suppliers' or the 'customers' timezone is, are we actually talking about some day concept perhaps from start of business. Representing this as a datetime start / end certainly makes it possible to represent these concepts, if perhaps not making anything else particularly easier.
- deleted 6y ago[deleted]
- zimpenfish 6y agoI was going to say that this has a weakness in testing because you can't `assert(end > start)` without knowing which is which because `assert(later > sooner)` will always be true but then I guess you'd have input (and other) validations before it got to that point anyway.