* There has been a great deal of anguish over the encoding of
weekdays: whether [0, 6] maps to [Sunday, Saturday] or
[1, 7] maps to [Monday, Sunday]. This commit attempts
to address that issue, but will break a small amount of
code at compile-time. See below on how to fix that.
* The weekday constructor used to accept [0, 6] to represent
[Sunday, Saturday]. It now accepts [0, 7] to represent
[Sunday, Saturday] with both 0 and 7 mapping to Sunday.
* The conversion from weekday to unsigned has been removed.
* To convert a weekday to unsigned replace:
auto u = unsigned{wd};
with:
auto u = (wd - Sunday).count();
This maps [Sunday, Saturday] to [0, 6], which is the
C/POSIX mapping. If you prefer the ISO mapping
([Monday, Sunday] -> [1, 7]), then do:
auto u = (wd - Monday).count() + 1;
* Added new overloads for operator+/- between year_month and duration
that is convertible to years, so it is better candidate for operands
that are convertible to both years and months. To preserve
functionality, this operator is conditionally noexcept.
* Reworked year_month_day, year_month_day_last, year_month_weekday,
and year_month_weekday_last.
* Added tests for this new functionality.
Change the implementation, in the way that mismatch in return
type of the from/to_sys/utc functions (not returning time_point,
or returning time_point with inappropriate clock) leads to
hard error.
Added appropariate fail test for to_sys function, including:
* returning an int
* returning time_point of wrong clock
* reutrning reference to time_point
Added test that detects if clock_cast<Dest>(Source) properly
SFINAEs if clock's are not castable, this includes test for
steady_clock that is not castable to any wall-clock.
Secondly added steady_based_clock based on steady_clock
(as name indicates), that clock_cast may be extended to clock
non-related to wall-time (sys/utc) using conversion traits.
Final example is pair of ambiguous clocks (amb1/amb2_clock) that can convert
to each other either using sys_clock or utc_clock.
Then the conversion from amb2 to amb1 is disambiguated
via trait specialization.
Created mil_clock and s2s_clock, that are both using to_sys/from_sys
function and are fully interoperable with existing clocks (including
ones based on utc).
Implemented an trait is used to provide direct conversion
from s2s_clock to mil_clock without converting to sys_clock
(conversion counter is used for this purpose).
Implemented test for conversions between existing clocks
(sys_clock, utc_clock, tai_clock, gps_clock) showing that
they can be used instead of to_clock_time functions.
* Avoids the need to download the IANA database.
* Heavily based on contributions by Aaron Bishop.
* Turn on with -DUSE_OS_TZDB, off by default.
* Not supported on Windows.
* Disables HAS_REMOTE_API.
* get_tzdb().version only supported on Apple. This string has
the value "unknown" elsewhere.
* Leap second support is missing on Apple, and may not be on your
platform either (please report). Leap second support is enabled,
disabled with -DMISSING_LEAP_SECONDS.
Without leap second support, utc_time, tai_time, and gps_time (and
those clocks) are not available.
* On Apple, time zone transitions are only supported in the range:
1901-12-13 20:45:52 to 2038-01-19 03:14:07
* On Linux, time zone transitions are only as far in the future as
the OS-provided transitions go. There is no support for POSIX-
style transitions.
* For format, all a type must do is implement to_stream.
* For parse, each type X must specialize parse_manip<X,CharT,Traits>.
Each specialization must include a public typedef to itself named
type.
* Each parse_manip specialization must have a stream extraction
operator.
* This commit depends on expression-SFINAE. If this commit breaks
your build, it is likely that your compiler/version does not
support expression-SFINAE. To fix this NO_EXPRESSION_SFINAE
needs to be defined in the configuration area of date.h for
that compiler/version.
Make validate work for C++11 because the library supports it.
Fix an unused variable mistake i made earlier.
Make constructor public, seems it should be. Possible compiler bug?
