VS2019 correctly points out that a conversion from a wide NTCS to std::string requires narrowing. This may result in an undesired string value. Implement the string conversion properly.
Signed-off-by: Daniela Engert <dani@ngrt.de>
- c_encoding satisfies ctime wday encoding: days since Sunday, range
[0,6]
- iso_encoding satisfies ISO 8601 weekday:
a digit d from 1 through 7, beginning with Monday and ending with Sunday
* These flags format a duration.
* %Q specifies the duration's numeric value.
* %q specifies the duration's SI abbreviation.
* Example: format("%Q %q", 45ms) == "45 ms"
'using namespace std;' in header files can conflict with custom
namespace names. For example 'string' is used without 'std::'
qualification. If tz.h is included in a file where string is a
namespace, it cannot be compiled anymore. The same happens with date.h
if ONLY_C_LOCALE=1.
Implemented clock_time_conversion<D, local_t> calling D::from_local
and clock_time_conversion<locat_t, S> calling S::to_local.
To avoid ambiguities addes:
* clock_time_conversion<local_t, local_t> - idenitity
* clock_time_conversion<local_t, utc_clock> - same as default (utc_clock::to_local)
* clock_time_conversion<utc_clock, local_t> - same as default (utc_clock::from_local)
In addition, as std::chrono::system_clock cannot be edited, added:
* clock_time_conversion<local_t, std::chrono::system_clock> - assumes same epoch
* clock_time_conversion<std::chrono::system_clock, local_t> - assumes same epoch
They will be required to resolve amibiguity anyway.
Implemented to_local and from_local functions for utc_clock,
tai_clock and gps_clock. For the tai/gps clock used this function
for defining the io - we delegate to serializing/parsing local
time.
The drwaback is that the local_time cannot properly represent
leap second in the UTC time, so separate serialization is needed.
* 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;
