Cppcheck 2.17 tool found issue with struct tm under Windows
Checking AK/Time.cpp ...
Checking AK/Time.cpp: AK_OS_WINDOWS...
AK/Time.cpp:488:15: error: Uninitialized variable: &tm [uninitvar]
(void)localtime_r(×tamp, &tm);
^
32/39 files checked 87% done
Also the gmtime_X` and localtime_X calls were not checked for failures,
so those are now checked too.
With numerators or denominators approaching NumericLimits<u32>::max(),
we could overflow in the sum of the remainder and the rounding
contribution. Instead, divide them separately and sum them afterward.
Overflow could happen in the multiplication of the remainder seconds
back into time units. Instead, take a remainder of the time units from
the division and use that for the nanoseconds.
When passed values that result in a negative integer number of seconds,
we would end up with a nanoseconds component that was outside the
allowed range in Duration. When we get an exact second of nanoseconds,
we can just increment the seconds and reset the nanoseconds to correct
this.
Fixes a crash on https://athenacrisis.com/#athena-crisis.
These take a numerator and denominator defining the unit in a fractions
of a second. Conversion is done in integers, meaning that these must
clamp when approaching numeric limits.
Copy parse() method from LibCore::DateTime::parse(). Augment the method
to handle parsing from GMT time. Fix incorrect handling of year in '%D'
format specifier. Remove all format specifiers related to time zones.
Copy relevant tests and add additional ones.
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
This allows us to make all comparision operators on the class constexpr
without pulling in a bunch of boilerplate. We don't use the `<compare>`
header because it doesn't compile in the main serenity cross-build due
to the include paths to LibC being incompatible with how libc++ expects
them to be for clang builds.
In practice, this function does not take any perceptible amount of time.
However, this benchmark demonstrates that for extreme values, the
internal for-loop does matter.
