diff --git a/Examples-and-Recipes.md b/Examples-and-Recipes.md
index 214ba62..7c7447e 100644
--- a/Examples-and-Recipes.md
+++ b/Examples-and-Recipes.md
@@ -731,6 +731,29 @@ Note that without handling the timezone correctly, this result would be an hour
 
 Also note that this library correctly handles the changes in timezone rules throughout the decades.  Several Apr 24ths have fallen within daylight saving over the decades, all of them since 1987.
 
+#### But what about leap seconds?
+
+This gets a little complicated.
+
+Atomic time keeping started experimentally in 1955, about a year after Dave's birth.  In 1958 the first atomic international time standard was begun: TAI.  And then between 1958 and 1972 10 "undocumented" leap seconds were inserted to form what we now know as UTC.  I say "undocumented" because they weren't inserted in units of a second, and I don't know how much was inserted when. I only know that the total was exactly 10s over this time period.
+
+Assuming the birthdate is exactly synchronized with TAI (offset by the timezone), then we can form the birthday as `tai_time`:
+
+    auto zone = locate_zone("America/Los_Angeles");
+    auto birthday = to_tai_time(make_zoned(zone,
+                    local_days{apr/24/1954} + 10h + 3min - 10s).get_sys_time());
+
+We have to subtract 10s manually because we want the birthday to be `1954-04-24 18:03:00 TAI` and without that 10s subtraction we have UTC modeled back to 1954 instead of modeling TAI in 1954.  Then we add the 2Gs in `tai_time` and convert that result back to `sys_time`, and then to a `zoned_time`:
+
+    auto Day2Gs = make_zoned(zone, to_sys_time(birthday + 2'000'000'000s));
+
+Now the output is:
+
+    born        : 1954-04-24 18:03:00 TAI 
+    2Gs birthday: 2017-09-08 14:35:43 PDT
+ 
+which is 37s earlier than we reported without taking leap seconds into account.  Now ordinarily computing times to this accuracy (taking leap seconds into account) in the future would be a very dicey proposition as you never know when a leap second is going to be inserted in the future.  However, as I write this (2016-10-24) the IANA database knows about the leap second to be inserted at 2017-01-01, and it is unlikely (though not impossible) that another leap second will be inserted prior to 2017-09-08.  So I have a high confidence that the correct number of leap seconds has been taken into account.  We should know for sure if this computation is exactly correct by 2017-02-01.
+
 <a name="year_day"></a>
 ### Calculating Ordinal Dates
 (by [Roland Bock](https://github.com/rbock))