[phobos] datetime review

[Jonathan M Davis]

On Sunday 10 October 2010 06:43:59 Andrei Alexandrescu wrote:
> Here's an unrelated suggestion that might simplify things a fair amount:
> drop the "months" and the "years" durations. They are the only ones that
> are irregular. Then you have only one duration type that's always
> precise and you can drop the interval type. If someone wants to figure
> out e.g. the number of months between two dates, we can provide specific
> functions.

It's not an altogether bad suggestion, but I think that it limits the 
expressiveness of the library. For instance, if you wanted to iterate over a 
range of Christmases, you would need to be able to indicate that you wanted a 
year between each date that you were iterating over. That is, each date in the 
range would be 1 year later than the previous one. You can't indicate that with 
a duration of days, because once you hit a leap year, you'll get December 24th 
instead of December 25th. You need to be able to indicate years.

Now, we _could_ have addXXX functions for months and years and use durations for 
everything else. It's a little bit awkward, but it would solve the range issue I 
just mentioned and still allow for the adding of months and years. The one 
problem that remains is that that makes it impossible to do something like 
Dur.months(5) + Dur.days(3) to indicate a duration of 5 months and 3 days. And 
creating a range function which iterates over successive dates which are 5 
months and 3 days apart would be much harder because you would have to use both 
the add function and a duration to do it.

Eliminating MonthDuration and JointDuration in favor of simply having 
HNSecDuration simplifies a fair bit of code, but it makes it very hard to mix 
months and years and anything smaller anywhere. So, it's tempting, but I'm not 
entirely sure if it's a good idea or not.

By having duration creation be entirely by functions without requiring the 
programmer to really have to care about the types of the durations, for the most 
part, you manage to be able to mix months and smaller units without causing 
problems for the programmer. It _does_ complicate the library itself, and it is 
certainly possible for it to cause problems for the user (like if they don't use 
auto or if they try and pass a duration to a function that they write), but it 
manages to avoid most of them.

So, I'm a bit torn on the issue. The extra complication is annoying, but if we 
go for a single duration type (or two if you count TickDuration), there's 
definitely code which gets simplified. On the other hand, other code becomes 
harder to write. In terms of the code that I've written which uses durations 
(which is primarily the unit tests), I think that the current solution generally 
works quite well, but then again, I understand the issues of MonthDuration vs 
HNSecDuration and am not confused by the multiple duration types. It's likely to 
be more confusing for someone who hasn't dealt with it before. On the other 
hand, if you're typically using durations in time code and you suddenly need to 
deal with months or years, the lack of ability to create durations of months or 
years would also be confusing and potentially frustrating.

So, I'm not really sure what the best solution is. For the most part, I like it 
how it is, but it certainly isn't ideal (then again, "ideal" isn't really 
possible due to the variable number of days in months and years). I'll have to 
think about it, and I really don't know what the average programmer would 
prefer, or how limiting it will be to the not-so average programmer who is 
really trying to leverage the library if they can't have durations of months or 
years.

- Jonathan M Davis