diff --git a/FAQ.md b/FAQ.md
index 1eacae5..64511be 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -8,7 +8,7 @@
 
 This library is meant to be a foundational library upon which you can efficiently build higher-level date libraries (like tz.h). A core component of this library is that it makes expensive computations explicit, so that you can see where they are in your code. Higher-level code can hide these expensive/explicit operations as desired.
 
-A good way to estimate the cost of any given date computation is to count the number of conversions from a field type (e.g. `year_month_day` or `year_month_weekday`) to a serial type (e.g. `day_point`), and vice-versa.  As an example, here is a real-world example (found in the issues list):
+A good way to estimate the cost of any given date computation is to count the number of conversions from a field type (e.g. `year_month_day` or `year_month_weekday`) to a serial type (e.g. `sys_days`), and vice-versa.  As an example, here is a real-world example (found in the issues list):
 
 We need to compute the day after the 3rd Tuesday of the month.  If day-oriented arithmetic was allowed on `year_month_weekday`, that would be in the form of a function like this:
 
@@ -16,7 +16,7 @@ We need to compute the day after the 3rd Tuesday of the month.  If day-oriented
     year_month_weekday
     operator+(const year_month_weekday& ymwd, const days& dd) noexcept
     {
-        return year_month_weekday{day_point{ymwd} + dd};
+        return year_month_weekday{sys_days{ymwd} + dd};
     }
 
 The programmer would probably use it like this:
@@ -29,10 +29,10 @@ The programmer would probably use it like this:
 
 That is super-compact syntax!  Here is what it costs:
 
-1. Convert `tue[3]/m/y` (`year_month_weekday`) to `day_point` in order to add `days`.
-2. Convert the `day_point` computed back to `year_month_weekday`.
-3. Convert the temporary `year_month_weekday` computed in 2 back to `day_point`.
-4. Convert the `day_point` to a `year_month_day`.
+1. Convert `tue[3]/m/y` (`year_month_weekday`) to `sys_days` in order to add `days`.
+2. Convert the `sys_days` computed back to `year_month_weekday`.
+3. Convert the temporary `year_month_weekday` computed in 2 back to `sys_days`.
+4. Convert the `sys_days` to a `year_month_day`.
 
 4 conversions.
 
@@ -41,13 +41,13 @@ Here is the way you have to write this function today (because `tue[3]/m/y + day
     year_month_day
     get_meeting_date(year y, month m)
     {
-        return year_month_day{day_point{tue[3]/m/y} + days{1}};
+        return year_month_day{sys_days{tue[3]/m/y} + days{1}};
     }
 
-The syntax is slightly more verbose in that you have to explicitly convert the `year_month_weekday` into a `day_point` in order to perform the day-oriented arithmetic.  Here is what it costs:
+The syntax is slightly more verbose in that you have to explicitly convert the `year_month_weekday` into a `sys_days` in order to perform the day-oriented arithmetic.  Here is what it costs:
 
-1. Convert `tue[3]/m/y` (`year_month_weekday`) to `day_point` in order to add `days`.
-2. Convert the `day_point` to a `year_month_day`.
+1. Convert `tue[3]/m/y` (`year_month_weekday`) to `sys_days` in order to add `days`.
+2. Convert the `sys_days` to a `year_month_day`.
 
 2 conversions.  Roughly twice as fast!