Replace following names:
std.typetuple -> std.meta
TypeTuple -> AliasSeq
ParameterTypeTuple -> Parameters
FieldTypeTuple -> Fields
std.traits requires more work than search/replace and is left unchanged.
This moves all of the private, helper templates for isTimePoint into
isTimePoint (which reduces code) and cleans up their implementation a
bit. The tests have also been improved to actually check types which are
supposed to be false with isTimePoint and the implementation adjusted
accordingly (previously, they failed to compile with isTimePoint rather
than resulting in false).
The checks for TickDuration have been removed in the process, since
we're getting rid of it. No code will break from that, since all it
means is that a type which passes isTimePoint no longer needs to work
with TickDuration. If it does work with TickDuration (as the time point
types in std.datetime will until it's been fully removed), then it will
just continue to work as it has.
This commit also improves the documentation, which was woefully vague.
We've had the ability to convert from unix time to SysTime, but it has
been more unwieldy than it should be. This adds fromUnixTime to go with
toUnixTime.
In addition, these changes solve the problem where you sometimes need a
value for unix time that doesn't fit in time_t (e.g. a 64-bit value on a
32-bit system), or you're dealing with a 64-bit time_t on a 32-bit
system (which Windows sometimes does). So, toUnixTime and
stdTimeToUnixTime now take an optional template argument which indicates
how many bits the result should be (defaulting to match the size of
time_t), and fromUnixTime and unixTimeToStdTime now take long rather
than time_t so that they can accept 64-bit values on 32-bit systems.
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.
