HowardHinnant/date
1
0
Fork 1
mirror of https://github.com/HowardHinnant/date.git synced 2025-08-04 13:14:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ (markdown)

Howard Hinnant
2018-05-19 19:39:22 -04:00
parent 7002745239
commit deb5abb609
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
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 `<time.h>` API. However the reality is that clients still often have to interoperate with legacy code that uses the old `<time.h>` 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 `<time.h>` API. However the reality is that clients still often have to interoperate with legacy code that uses the old `<time.h>` 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};
```