diff --git a/d0355r4.html b/d0355r4.html index 6a569d4..cde2b27 100644 --- a/d0355r4.html +++ b/d0355r4.html @@ -37,7 +37,7 @@ Document number: D0355R4

Howard E. Hinnant
-2017-08-12
+2017-08-13

Extending <chrono> to Calendars and Time Zones

@@ -216,10 +216,9 @@ Everything proposed herein has been fully implemented here:

-The implementation includes full documentation, and an -active -community of users with positive field experience. The implementation has been ported -to Windows, Linux, Android, macOS and iOS. +The implementation includes full documentation, and an active community of users with +positive field experience. The implementation has been ported to Windows, Linux, Android, +macOS and iOS.

@@ -652,80 +651,6 @@ 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 client 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 -const 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 << zoned_time{current_zone(), system_clock::now()} << '\n';
-
    -

    -We simply need to decide if the default style guide for passing time_zones -around is const time_zone* or const time_zone&. And yes, -it is ok for a client to have a const time_zone* which equals -nullptr. And no, the library never provides a const time_zone* -which is equal to nullptr. -

    -
    3. - -
-

Proposed Wording

Table of Contents for Proposed Wording

@@ -9117,7 +9042,7 @@ struct tzdb class tzdb_list { - std::atomic head_{nullptr}; // exposition only + std::atomic<tzdb*> head_{nullptr}; // exposition only public: class const_iterator; @@ -9234,8 +9159,8 @@ const time_zone* current_zone();

-tzdb_list::const_iterator is a non-mutating iterator which meets the -forward iterator requirements. +tzdb_list::const_iterator is a constant iterator which meets the +forward iterator requirements and has a value type of tzdb. 
 const tzdb& tzdb_list::front() const noexcept;