the question of why that is the way it is, it's because we
actually
thought of all that shit when designing the time library :) I
was a big
proponent of not using the same type to mean duration and
timestamp, and
only allowing sane operations. Jonathan was the same way.
That separation is one of the main reasons for introducing
I would like to express my appreciation to the implementors (I
guess Jonathan and Stephen) as well as to the Phobos guardians
for taking the pains to implement the datetime library in a
thoughtful and conscious way.
Dates are not conventionally the most glamorous part of a
library, but they are very important in some key use cases for D.
Much of finance is about net present value, and for that you
need to get datetimes right. Every swap has a bunch of
cashflows, and you need to apply various market conventions in
generating these. Eg cashflows are every three months, and you
roll forward if the payment day is a holiday, unless that would
take you to the next month, in which case you roll backwards.
Similarly for analyzing high frequency data, one needs to be able
to work easily with timestamps.
I was so frustrated by numpy's datetime64 that I ended up rolling
my own, so it is encouraging that my new chosen platform (D)
natively does a much better job.
The level of attention to detail, high standards, and
appreciation of beauty are some of the best things about the
language and the people here.
On a different note, and having read the discussion Jonathan
linked to: bounded int, and better messages about template
constraints would certainly be things I would find helpful.
