endOfMonthDay is too close to endOfMonth, and std.date had daysInMonth
(which amounts to the same thing), so I'm renaming endOfMonthDay to
daysInMonth. So, endOfMonthDay is now scheduled for deprecation. I also
adjusted the various deprecation messages related to std.datetime so
that they included the month when the items in question would be deprecated.
std.gregorian, std.date, and std.dateparse have all been marked as
scheduled for deprecation. Everywhere (except for std.file) which was
using std.date is now using std.datetime. std.file is now using
std.datetime but has a number of functions still using d_time but which
are marked as scheduled for deprecation. I tried to give as many as I
could pragmas indicating that they were scheduled for deprecation, but
at the moment, that requires that a function be a templated function, and
I couldn't templatize all of them. So, some functions in std.file are
only marked as scheduled for deprecation in their documentation and will
not give any warning on compilation.
I had to rename several functions in std.file in order to avoid making
any breaking changes. And since I was already having to mess with
function names, it seemed like a good time to change the names of a
number of the functions in std.file to use proper capitalization
(such as changing isdir to isDir) as has been discussed and overwhelmingly
supported in the newsgroup with regards to std.string. And since I was
making those changes, it seemed like a good time to fix bug# 3848
(functions in std.file don't take symbolic links into account) as well.
So, std.file should now deal with symlinks properly.
The issue which Andrei brought up with +VERSION causing the std.datetime
unit tests to fail on OSX has been fixed as well.
