From dd209e205e6e1e78730553b0d3f49354417f2444 Mon Sep 17 00:00:00 2001 From: Howard Hinnant Date: Sat, 15 Oct 2016 21:02:01 -0400 Subject: [PATCH] Add issues list to d0355r1 --- d0355r1.html | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/d0355r1.html b/d0355r1.html index 9070e35..a3ad7c5 100644 --- a/d0355r1.html +++ b/d0355r1.html @@ -42,6 +42,7 @@ Document number: D0355R1
  • Revision History
  • Introduction
  • Description
    • +
  • Issues
  • Proposed Wording
  • Acknowledgements
  • References
    • @@ -569,6 +570,72 @@ please see: http://howardhinnant.github.io/date/iso_week.html +

    Issues

    + +

    +This is a collection of issues that could be changed one way or the other with this +proposal. +

    + +
      +
    1. +

      +Can the database be updated by the program while the program is running? +

      +

      +This is probably the most important issue to be decided. This decision, one way or +the other, leads (or doesn't) to many other decisions. If the database can be updated +while the program is running: +

      +
        +
      1. Is the cleint responsible for thread safety issues? This proposal says yes.
        2. +
      2. What is the format of the database? This proposal says it is the text format +of the IANA database.
        3. +
      3. Can the database be updated to the latest version at a remote server on application +startup? This proposal says yes. This means Egypt-like time-zone changes (3 days +notice) can be handled seamlessly.
        4. +
      +

      +Not allowing the database to be dynamically updated is by far the simpler solution. +This proposal shows you what dynamic updating could look like. It is far easier to +remove this feature from a proposal than to add it. This proposal is designed in such +a way that it is trivial to remove this functionality. +

      +
      2. + +
    2. +

      +Currently this library passes time_zones around with +const time_zone*. Each time_zone is a non-copyable singleton +in the application (much like a type_info). Passing them around by pointers +allows syntax such as: +

      +
      +auto tz = current_zone();
+cout << tz->name() << '\n';
+
      +

      +But source functions such as current_zone and locate_zone +never return nullptr. So it has been suggested that the library +traffic in const time_zone& instead. This would change the above +code snippet to: +

      +
      +auto& tz = current_zone();
+cout << tz.name() << '\n';
+
      +

      +Either solution is workable. And whichever we choose, the client can get the other +with *current_zone() or &current_zone(). And whichever +we choose, we will make the library API self-consistent so that things like +the following work no matter what with this syntax: +

      +
      +cout << make_zoned(current_zone(), system_clock::now()) << '\n';
+
      +
      3. +
    +

    Proposed Wording