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.
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.
