4 ms·
The time period example seems to miss an obvious weakness in the described Time Period 'object' - it's implied that the end date should be >= the start, but if
by joosters 6y ago
The time period example seems to miss an obvious weakness in the described Time Period 'object' - it's implied that the end date should be >= the start, but if you are representing a time period with ( Date, Date ) then you are still allowing invalid states to be represented - yet this is what the writer is trying to avoid. Likewise, a timeline split into contiguous periods can still represent out-of-order Dates.
a Time Period object of ( Date, Duration ) would fix the first issue, and a TimeLine of ( Date, Duration, Duration, ... ) would fix the second one (assuming unsigned Durations!)
- jxf 6y agoI 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.
- choeger 6y agoYou should re-read the article. The author explicitly mentions to use sets of dates. Hence the ordering is implicit. For an interval you can do the same and use either a set or an unordered pair.
- joosters 6y agoA set doesn't necessarily imply an ordering (unless this article is about some specific programming language, but it seemed fairly generic to me). e.g. Java and C++ have many Set implementations, some sorted (e.g. a TreeSet) and some not (e.g. HashSet)
- matsemann 6y agoThat's the point. There's no ordering of the items. So the representation can never have an error like [yesterday, tomorrow, today]. It's just a set of (yesterday, tomorrow, today).
- secondcoming 6y agoSo finding out a contract type from a timestamp is linear?
- joosters 6y agoDoesn't that just push all the responsibility onto every piece of code that uses the datatype? 'Remember to sort the contents of this set every time before using it' sounds like it is asking for trouble.
- kevinmgranger 6y agoThe fact that it's a set can be hidden, and any queries that depend upon an ordering can be presented as a sorted view or whatnot.
- rocqua 6y agoThe set, and an ordering over the elements is sufficient. It perfectly defines and represents the intervals mathematically. What implementation of a set you use is a practical detail. When implementing this in practice, you probably want to use a set implementation that gives fast ordering results. But that is a performance consideration. Not a data-representation consideration.
- deleted 6y ago[deleted]
- lxe 6y agoI think the example's last visualization is confusing. The timeline is {date1, date2, date3, date4}. Let's say you have 2 periods, date1 - date3, and date2 - date4. Period 1 can be represented as {date1, date2, date3}. Period 2 can be {date2, date3, date4}. Am I understanding this correctly?