[phobos] datetime review

[Jonathan M Davis]

On Sunday 10 October 2010 07:45:14 Andrei Alexandrescu wrote:
> Again, the action item is to find realistic use cases.

Okay. If all you're doing is adding to a time point, then addYears() and 
addMonths() works just fine. It's a bit odd to have addYears() and addMonths() 
but uses durations for all of the other units, but it's likely less confusing 
than having the separate types MonthDuration and HNSecDuration.

Now, it doesn't work as well for generic code to have add functions for months 
and years but durations for everything else. You have to special case years and 
months whereas with MonthDuration and HNSecDuration you don't have to as long as 
you templatize your duration types. With MonthDuration and HNSecDuration, most 
of the special casing is in the time point and duration types, so the programmer 
doesn't have to worry about special casing stuff.

The really big gain fo being able to do something like Dur.months(5) + 
Dur.days(2) and have a duration with both months and days is that it makes it a 
lot easier to do fancy stuff with ranges. You can specify any combination of time 
units to specify very exact durations between time units. Without durations with 
months or years, that becomes much more awkward. I'm not sure how likely it is 
that someone would be interested in iterating over succesive dates which are odd 
durations apart like 2 months and 7 days though. It may make it easier to do a 
proper implementation of date recurrence patterns (RFC 2445, I believe), but 
since that's already going to require a potentially extensive library to make 
that work, it could likely abstract away any of the difficulties in having a range 
which iterates over time points which are apart by more eccentric durations.

It wouldn't be all that hard to create a function which took the number of 
years, months, and a duration to generate a range function, and that would be 
far more awkward than Dur.months(5) + Dur.days(3), but it wouldn't be all that 
bad, and it would seriously simplify a lot of the rest of std.datetime.

Really, the only major case that I can think of is that being able to generate 
arbitrary durations is useful when dealing with ranges. If you're simply trying 
to add a duration to a time point, it's not much worse to have to explicitly use 
addYears and/or addMonths in addition to adding a duration to the time point (a 
bit annoying perhaps, but not a big deal). Generic code also does better with 
durations (though we could always keep addTUnit() and that would solve the 
generic code issue just fine), but I question that that's all that big a deal.

Part of me would definitely like to keep MonthDuration, HNSecDuration, and 
JointDuration as is, but the more I think about it, the more it looks like it 
wouldn't be all that bad to have to work around their lack, and while using the 
durations as they are really isn't all that hard, it's going to confuse a fair 
number of people when they first encounter them. So, I'm beginning to lean 
towards just simplifying it to HNSecDuration (though I'd rename it as Duration 
in that case). It's annoying in some cases, but it'll definitely cut down on the 
learning curve for using the library.

Much as auto pretty much saves the day, it's pretty much a guarantee that there 
are programmers who will want to (or will think that they have to) actually 
worry about the specific duration types, no matter how good a job I do at making 
it so that they don't have to worry about it. I know that there are programmers 
who have worried about that sort of thing with std.algorithm and been scared off 
by it, when they don't really need to care thanks to auto.

- Jonathan M Davis