[Git][NTPsec/ntpsec][master] 3 commits: Correct the actual GPS rollover time

[Matt Selsky]

Matt Selsky pushed to branch master at NTPsec / ntpsec


Commits:
89082f06 by Sanjeev Gupta at 2019-08-21T18:17:24Z
Correct the actual GPS rollover time

GPS rolls over at "midnight" GPS Time, not Zulu

    See:
    https://galileognss.eu/gps-week-number-rollover-april-6-2019/
    http://bit.ly/30u1aIk

- - - - -
e41620a6 by Sanjeev Gupta at 2019-08-21T18:34:04Z
Expand references on leap smearing

- - - - -
c3f2d255 by Sanjeev Gupta at 2019-08-21T18:46:02Z
Update leapsmear.adoc

* Document that most of the information is historic,
  to NTP Classic
* Document the Google and AWS implemetations

- - - - -


2 changed files:

- docs/leapsmear.adoc
- docs/rollover.adoc


Changes:

=====================================
docs/leapsmear.adoc
=====================================
@@ -37,8 +37,8 @@ timestamps can occur.
 
 Unfortunately there are lots of applications which get confused if the
 system time is stepped back, e.g. due to a leap second insertion.  Thus,
-many users have been looking for ways to avoid this, and have tried to introduce
-workarounds which may or may not work properly.
+many users have been looking for ways to avoid this, and have tried to
+introduce workarounds which may or may not work properly.
 
 So even though these Unix kernels normally can handle leap seconds, the way
 they do this is not always optimal for applications.
@@ -173,6 +173,8 @@ the normal refid, as usual.
 The leap smear implementation is optionally available in ntp-4.2.8p3 and
 later, and the changes can be tracked via https://bugs.ntp.org/2855.
 
+Please note that the above is historical, NTPSec forked from Classic
+after this point.
 
 == Using NTP's Leap Second Smearing
 
@@ -233,6 +235,11 @@ drift caused by the smeared time, and with longer values the discrepancy
 between system time and UTC will cause more problems when reconciling
 timestamp differences.
 
+A value of 86400 is what is implemented by
+https://developers.google.com/time/smear["Leap Smear"] and
+https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/["Look Before You Leap"] .
+
+
 When ntpd starts and a smear interval has been specified then a log message
 is generated, e.g.:
 


=====================================
docs/rollover.adoc
=====================================
@@ -157,10 +157,16 @@ seconds, which does not participate in the seconds counter's rollover
 problems.
 
 NTP time is leap second corrected, and the reference implementation
-may exhibit stutter or skip.  There is a controversial technique
-called https://developers.google.com/time/smear["leap smearing"] used
+may exhibit stutter or skip.
+
+There is a technique called
+https://developers.google.com/time/smear["leap smearing"] used
 by some servers that avoids these by changing the length of the issued
-second slightly near scheduled corrections.
+second slightly before and after the leap. The AWS equivalent is at
+https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/["Look Before You Leap"] .
+
+Leap Smear is supported by NTPSec, please see
+link:leapsmear.html[Leap Second Smearing with NTP] .
 
 === GPS time
 
@@ -170,8 +176,10 @@ constraints at the time the system was designed, the week counters are
 only 10 bits long; thus, GPS time has a period of 1024 weeks (a bit
 over 19 years).  At time of writing, two GPS rollovers
 have occurred; the first at 1999-08-22T00:00:00 and the second at
-2019-04-06T00:00:00.  Note that these times are "GPS Time", not
-UTC.
+2019-04-07T00:00:00.  Note that these times are "GPS Time", not
+UTC, the corresponding UTC was 2019-04-06T23:59:42Z , ie a
+difference of the 18 leapseconds that had elapsed since the
+GPS epoch.
 
 It is planned that future GPS satellites will increase the week
 counter length to 13 bits, for a period of 8192 weeks or more
@@ -206,7 +214,7 @@ every possible dime out of their costs.  Even major vendors like
 SiRF have a history of embarrassing firmware glitches, and the
 semi-anonymous outfits in Shenzhen and Taiwan are worse.
 
-Cheaper,consumer-grade, GPS devices also suffer from early EOL, and
+Cheaper, consumer-grade, GPS devices also suffer from early EOL, and
 manufacturers may never release firmware updates.
 
 The worst impact of careless, low-budget design when using a GPS as



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/79341a8a834583de7676f2926926a6e9e0ba89b7...c3f2d25503803f924d1235346e19c5bf14d0d332

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/79341a8a834583de7676f2926926a6e9e0ba89b7...c3f2d25503803f924d1235346e19c5bf14d0d332
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190823/1a610ae2/attachment-0001.htm>