From 0aeb2389ef54ac706f5a1469d242bc6c88463b47 Mon Sep 17 00:00:00 2001 From: Howard Hinnant Date: Mon, 30 May 2016 15:08:46 -0400 Subject: [PATCH] Address review comments --- d0355r0.html | 90 ++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 81 insertions(+), 9 deletions(-) diff --git a/d0355r0.html b/d0355r0.html index 29319a2..86e161a 100644 --- a/d0355r0.html +++ b/d0355r0.html @@ -31,7 +31,7 @@ Document number: D0355R0

Howard E. Hinnant
-2016-05-29
+2016-05-30

Extending <chrono> to Calendars and Time Zones

@@ -75,12 +75,12 @@ main()

The above example creates a date in the Gregorian calendar (proposed) with the literal 2016y/may/29. The meaning of this literal is without -question. It is clearly readable. This proposal has no knowledge whatsoever of -the Coptic calendar. However it is relatively easy to create a Coptic calendar -(which knows nothing about the Gregorian calendar), which will convert to and -from the Gregorian calendar. This is done by establishing a clear and simple -communication channel between calendar systems and the -<chrono> library (specifically a +question. It is conventional and clearly readable. This proposal has no +knowledge whatsoever of the Coptic calendar. However it is relatively easy to +create a Coptic calendar (which knows nothing about the Gregorian calendar), +which will convert to and from the Gregorian calendar. This is done by +establishing a clear and simple communication channel between calendar systems +and the <chrono> library (specifically a system_clock::time_point with a a precision of days).

@@ -314,7 +314,7 @@ static_assert(ymd == sun[5]/may/2016); The literal sun[5]/may/2016 means "the 5th Sunday of May in 2016." The conventional syntax is remarkably readable. Constructor syntax is also available to do the same thing. The type constructed is -year_month_weekday which does nothing, but store a +year_month_weekday which does nothing but store a year, month, weekday, and the number 5. This "auxiliary calendar" converts to and from sys_days just like year_month_day as demonstrated above. As such, @@ -388,7 +388,7 @@ by default, you see the full precision of the zoned_time.

Sometimes, instead of specifying the time in UTC as above, it is convenient to specify the time in terms of the local time of the time zone. It is very easy to change the -above example to mean 7:30 JST instead of 16:30 JST: +above example to mean 7:30 JST instead of 7:30 UTC: 

@@ -465,6 +465,78 @@ cout << format(locale{"fi_FI"}, "%c", make_zoned("Europe/Helsinki", zt)) &
 // Ti 21 Kes 16:00:00 2016
+

+Wait, slow down, this is too much information! Let's start at the beginning. +How do I get the current time? +

+ +
+cout << system_clock::now() << " UTC\n";
+// 2016-05-30 17:57:30.694574 UTC
+
+ +

+My current local time? +

+ +
+cout << make_zoned(current_zone(), system_clock::now()) << '\n';
+// 2016-05-30 13:57:30.694574 EDT
+
+ +

+Current time in Budapest? +

+ +
+cout << make_zoned("Europe/Budapest", system_clock::now()) << '\n';
+// 2016-05-30 19:57:30.694574 CEST
+
+ +

+For more documentation about the calendar portion of this proposal, including more +details, more examples, and performance analyses, please see: +

+ +
+http://howardhinnant.github.io/date/date.html +
+ +

+For a video introduction to the calendar portion, please see: +

+ +
+https://www.youtube.com/watch?v=tzyGjOm8AKo +
+ +

+For more documentation about the time zone portion of this proposal, including more +details, and more examples, please see: +

+ +
+http://howardhinnant.github.io/date/tz.html +
+ +

+For more examples, some of which are written by users of this library, please see: +

+ +
+https://github.com/HowardHinnant/date/wiki/Examples-and-Recipes +
+ +

+For another example calendar which models the +ISO week-based calendar, +please see: +

+ +
+http://howardhinnant.github.io/date/iso_week.html +
+

Proposed Wording