From deb5abb60957532115827cbeb46adc8332d4ecc5 Mon Sep 17 00:00:00 2001 From: Howard Hinnant Date: Sat, 19 May 2018 19:39:22 -0400 Subject: [PATCH] Updated FAQ (markdown) --- FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FAQ.md b/FAQ.md index e409a5f..8e7236c 100644 --- a/FAQ.md +++ b/FAQ.md @@ -164,7 +164,7 @@ This better support takes two forms: Reducing the importance of the encoding on But ultimately this library chose the [0, 6] encoding. Why? -This library was written to enable clients to abandon the ancient C/POSIX `` API. However the reality is that clients still often have to interoperate with legacy code that uses the old `` API. This old API using the [0, 6] encoding for the `tm_wday` member of the `struct tm`. It is easier on the client to maintain encoding compatibility with `struct tm` than it is if this library rigidly stuck to the ISO encoding. With this compatibility, filling out the `tm_wday` member of `struct tm` is as easy as: +This library was written to enable clients to abandon the ancient C/POSIX `` API. However the reality is that clients still often have to interoperate with legacy code that uses the old `` API. This old API uses the [0, 6] encoding for the `tm_wday` member of the `struct tm`. It is easier on the client to maintain encoding compatibility with `struct tm` than it is if this library rigidly stuck to the ISO encoding. With this compatibility, filling out the `tm_wday` member of `struct tm` is as easy as: ```c++ tm.tm_wday = unsigned{wd}; ```