diff --git a/pep-0418.txt b/pep-0418.txt
index e4d5a7e08..3f66718c3 100644
--- a/pep-0418.txt
+++ b/pep-0418.txt
@@ -22,8 +22,8 @@ Rationale
 =========
 
 If a program uses the system time to schedule events or to implement
-a timeout, it will not run events at the right moment or stop the
-timeout too early or too late when the system time is set manually or
+a timeout, it may fail to run events at the right moment or stop the
+timeout too early or too late when the system time is changed manually or
 adjusted automatically by NTP.  A monotonic clock should be used
 instead to not be affected by system time updates:
 ``time.monotonic()``.
@@ -36,13 +36,14 @@ very bad on Unix.  The new ``time.perf_counter()`` function should be
 used instead to always get the most precise performance counter with a
 portable behaviour (ex: include time spend during sleep).
 
-To measure CPU time, Python does not provide directly a portable
-function.  ``time.clock()`` can be used on Unix, but it has a bad
+Until now, Python did not provide directly a portable
+function to measure CPU time.  ``time.clock()`` can be used on Unix,
+but it has bad
 precision.  ``resource.getrusage()`` or ``os.times()`` can also be
 used on Unix, but they require to compute the sum of time
 spent in kernel space and user space.  The new ``time.process_time()``
 function acts as a portable counter that always measures CPU time
-(doesn't include time elapsed during sleep) and has the best available
+(excluding time elapsed during sleep) and has the best available
 precision.
 
 Each operating system implements clocks and performance counters
@@ -141,8 +142,9 @@ consecutive calls is valid and is a number of seconds.
 
 On Windows versions older than Vista, ``time.monotonic()`` detects
 ``GetTickCount()`` integer overflow (32 bits, roll-over after 49.7
-days): it increases a delta by 2\ :sup:`32` each time that an overflow
-is detected.  The delta is stored in the process-local state and so
+days).  It increases an internal epoch (reference time by) 2\
+:sup:`32` each time that an overflow is detected.  The epoch is stored
+in the process-local state and so
 the value of ``time.monotonic()`` may be different in two Python
 processes running for more than 49 days. On more recent versions of
 Windows and on other operating systems, ``time.monotonic()`` is
@@ -563,7 +565,7 @@ Example partial implementation:
 Working around operating system bugs?
 -------------------------------------
 
-Should Python ensure manually that a monotonic clock is truly
+Should Python ensure that a monotonic clock is truly
 monotonic by computing the maximum with the clock value and the
 previous value?
 
@@ -578,7 +580,7 @@ Python may only work around a specific known operating system bug:
 `KB274323`_ contains a code example to workaround the bug (use
 GetTickCount() to detect QueryPerformanceCounter() leap).
 
-Issues of a hacked monotonic function:
+Issues with "correcting" non-monotonicities:
 
 * if the clock is accidentally set forward by an hour and then back
   again, you wouldn't have a useful clock for an hour
@@ -946,7 +948,7 @@ mach_absolute_time
 ^^^^^^^^^^^^^^^^^^
 
 Mac OS X provides a monotonic clock: mach_absolute_time().  It is
-based on absolute elapsed time delta since system boot.  It is not
+based on absolute elapsed time since system boot.  It is not
 adjusted and cannot be set.
 
 mach_timebase_info() gives a fraction to convert the clock value to a