Previously, it formatted the time zone the same as toISOExtString and
put a colon between the hours and minutes - which is correct for the ISO
extended format, but not the non-extended format. Now, it formats it
correctly per the ISO 9601 standard.
fromISOString temporarily accepts both the extended and non-extended
formats to avoid breaking any programs that have been writing out ISO
strings to read back in later, but eventually, we'll make it so that it
only accepts the non-extended format like it's supposed to.
It's proven to be a maintenance problem to maintain the time zone
conversions between the IANA TZ database names and the Windows time zone
names in std.datetime. So, rather than compiling them in, this provides
a way to get them at runtime (which will also make it so in the future,
older releases can work properly on up-to-date Windows boxes, which is
not the case currently with regards to time zone conversions). The
current conversion functions can be deprecated after parseTZConversions
has been out for a release (so that it's possible for users to compile
their code for two releases in a row without getting deprecation
messages).
GetTimeZoneInformation is a Windows API function, and thus will never
throw a D exception. Presumably, at the time this code was written,
it was not marked as nothrow. However, instead of fixing the function's
signature, the code contained try/catch blocks with messages such as
assert(0, "The impossible happened. GetTimeZoneInformation() threw.");
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.
