[gpsd-dev] [PATCH 1/2] Clean language, typos

[Sanjeev Gupta]

---
 timebase.c | 56 ++++++++++++++++++++++++++++----------------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/timebase.c b/timebase.c
index 6420c1b..bb8d478 100644
--- a/timebase.c
+++ b/timebase.c
@@ -2,12 +2,12 @@
 
 All of gpsd's assumptions about time and GPS time reporting live in this file.
 
-This is a work in progress.  Currently GPSD requires that the host system
-clock be accurate to within one second.  It would be nice to relax this
-to "accurate within one GPS rollover period" for receivers reporting
-GPS week+TOW, but isn't possible in general.
+This is a work in progress.  Currently (3.11) GPSD requires that the host 
+system clock be accurate to within one second.  It would be nice to relax 
+this to "accurate within one GPS rollover period" for receivers reporting
+GPS week+TOW, but this isn't possible in general.
 
-= Begin Sidebar =
+= Begin Sidebar: Why Leap Seconds =
 
 READ this carefully, and if there are errors, please correct.  An
 understanding of the following terms is critical to make sense of the
@@ -22,29 +22,30 @@ We discuss four timescales:
  2. GPS Time, which ticks at at the rate of TAI, but has a constant offset
     from it.  For other GNSS systems, the offset is different.  The
     offset is of purely historical interest, being chosen by each
-    GNSS operator for convinience when the systems were inaugurated.
+    GNSS operator for convenience when the systems were inaugurated.
+    In other words, only the "epoch" differs between GPS Time and TAI.
  3. UT1, a smoothed earth rotation angle, which MUST return to zero
     once a day, (why?  Because you want the sun to be overhead *each*
     day at the same time on your watch, no?), and ticks SI seconds
     (a non-integeral number of seconds will occur in a UT1 day,
-    obviously).  For those of you who still say GMT, UT1 is the
+    obviously).  For those of you who still say "GMT", UT1 is the
     closest modern timescale.
  4. UTC, Coordinated Universal Time, which ticks SI seconds.  An attempt is
     made to keep UTC aligned with the rate of flow of seconds (TAI), and
     the rate of flow of days (UT1).
 
-The reason UTC has to struggle has little to do with the fact that the
-earth's rotation is slowing down.  Although the length of the day, as
-measured by UT1, is lengthening in terms of the SI second, this is a very
-long term slowdown, and since 1980, the earth has actually speeded up.
+The reason UTC has to struggle has little to do with the fact that the earth's
+rotation is slowing down.  Although the length of the day, as measured by UT1,
+is lengthening in terms of the SI second, this is a very long term slowdown,
+and since 1980, the earth has actually speeded up.
 
 The issue simply is that the term "second" is defined in two incompatible ways:
 
   Def 1. As a fixed number (9,192,631,770) of cycles of an atomic standard.
     We believe this is a constant, and evidence to the contrary may
-    involve GPSD code review, and Nobel Prizes.
+    involve GPSD code review, and Nobel Prizes.  This is the SI second.
   Def 2. As 1/86400 of a "day".  The number 86400 arises from
-    1 day == 24 * 60 * 60 secs
+    1 day == 24 * 60 * 60 secs.  This is what we learn in school.
 
 Both of these have been defined separately, and the issue of leap seconds,
 rubber seconds, Smoothed Leap Seconds, etc, arises because we are
@@ -52,18 +53,17 @@ unwilling to change the definition of either to be a 
derived unit of the
 other.
 
 At the time the SI second was defined, it was believed that Def 2 was correct,
-and the number in Def 1 was derived.  Because of ease of measurement,
-Def 1 was codified, and the problem was ignored for some time.  Prior
-to 1972, complicated formulae were used to scale the SI second, with
-the attendant confusion and fear that the formula would be revised.
-
-Since 1972, the start of UTC, the decision to have leap seconds means that
-UTC ticks SI seconds.  Every 86400 SI seconds, we declare a new day, and
-we let the error (UT1 - UTC) build up. This is of the order of a few ms
-each midnight, not always the same way (think eartquakes that move the
-earth's crust).
-
-Once the error has built up substantially, in a few years, we (and by
+and the number in Def 1 was derived.  Because of ease of measurement, Def 1 was
+codified, and the problem was ignored for some time.  Prior to 1972,
+complicated formulae were used to scale the SI second, with the attendant
+confusion and fear when the formula would be revised.
+
+Since 1972, the start of UTC, the decision to have leap seconds means that UTC
+ticks SI seconds.  Every 86400 SI seconds, we declare a new day, and we let the
+error (UT1 - UTC) build up. This is of the order of a few ms each midnight, not
+always the same way (think earthquakes that move the earth's crust).
+
+Once the error has built up substantially, every few years, we (and by
 "we", I mean M Daniel Gambis at the IERS) declare that a future
 day will have 86401 secs.  This is the Leap Second.  Note that this
 often overcorrects, but if we wait a few months, the error will disappear.
@@ -86,20 +86,20 @@ Two last things:
 
 
 Date and time in GPS is represented as number of weeks mod 1024 from
-the start of zero second of 6 January 1980, and number of seconds into
+the start of zero second of 6 January 1980, and number of SI seconds into
 the week.  GPS time is not leap-second corrected, and has a constant
 offset from TAI.  Satellites also broadcast a current leap-second
 correction which is updated on (theoretically) three-month boundaries
 according to rotational bulletins issued by the International
 Earth Rotation and Reference Systems Service (IERS).
-Historically all corrections have been issued on six-month boundaries.
+Historically all corrections have been made on six-month boundaries.
 
 The leap-second correction is only included in the satellite subframe
 broadcast, roughly once ever 20 minutes.  While the satellites do
 notify GPSes of upcoming leap-seconds, this notification is not
 necessarily processed correctly on consumer-grade devices, and will
 not be available at all when a GPS receiver has just
-cold-booted. Thus, the time reported from NMEA devices, although
+cold-booted.  Thus, the time reported from NMEA devices, although
 supposed to be UTC, may be offset by an integer number of seconds
 between a cold boot or leap second and the following
 subframe broadcast. 
-- 
1.8.5.1