This adds an option for getting the time using an alternative clock
chosen via core.time.ClockType, including access to a coarser clock as
requested by issue# 13433.
For ClockType.normal, the normal clock which has always been used is
used.
For ClockType.coarse, a faster clock is used if available even if it's
coarser so long as it still has sub-second precision, and the normal
clock is used if no such clock is available.
For ClockType.precise, a more precise clock is used if available
(currently only on FreeBSD), otherwise the normal clock is used.
For ClockType.second, a faster clock is used which only has second
precision. If no such clock is available, then the normal clock is used,
but the result is truncated to second precision.
The std.datetime unit tests currently fail on FreeBSD 9+ because of a
bug in FreeBSD itself (which it looks like Martin reported):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168862
tzname[] is set incorrectly in many time zones - including
America/Los_Angeles, which is what's causing the unit test failures in
std.datetime.
Sadly, the bug report has been around for almost 3 years without the bug
getting fixed (with the report including a patch no less), so I don't
know how long it will take them, and it just seems better to version out
the test in FreeBSD for now, since it's potentially a blocker for anyone
developing Phobos on FreeBSD.
The autotester doesn't exhibit the problem, because it's using FreeBSD
8.x.
Vladamir has a use case where the deprecation gives him a wall of
deprecation messages, and because he needs to use both 2.066 and master,
he can't move his code over to fracSecs yet. So, I'm changing the
deprecation to "scheduled for deprecation" for one release. And because
of this case, I think that I'm going to change the general policy to
"scheduling for deprecation" for one release before actually deprecating
a symbol. The fact that deprecated just generates a message mostly
obviates the need for "scheduling for deprecation" like we used to do,
but with this change, it will give folks one release to avoid the wall
of deprecation messages if they happen to use the deprecated symbol a
lot (or just once in a frequently instantiated template as in Vladamir's
case). It probably won't do anything for anyone who doesn't read the
changelog, but it will help out the folks who do.
I also added a script at the bottom of std.datetime which can be used to
regenerate the conversions from the latest conversion file at
unicode.org so that it will be much easier to make such updates in the
future.
