[COOK-4007] - update to 3612902400

Signed-off-by: Sean OMeara <[email protected]>

files/default/ntp.leapseconds

@@ -1,10 +1,10 @@
 #
 #	In the following text, the symbol '#' introduces
-#	a comment, which continues from that symbol until
+#	a comment, which continues from that symbol until 
 #	the end of the line. A plain comment line has a
 #	whitespace character following the comment indicator.
-#	There are also special comment lines defined below.
-#	A special comment will always have a non-whitespace
+#	There are also special comment lines defined below. 
+#	A special comment will always have a non-whitespace 
 #	character in column 2.
 #
 #	A blank line should be ignored.
@@ -17,23 +17,23 @@
 #	The first column shows an epoch as a number of seconds
 #	since 1900.0 and the second column shows the number of
 #	seconds that must be added to UTC to compute TAI for
-#	any timestamp at or after that epoch. The value on
+#	any timestamp at or after that epoch. The value on 
 #	each line is valid from the indicated initial instant
-#	until the epoch given on the next one or indefinitely
+#	until the epoch given on the next one or indefinitely 
 #	into the future if there is no next line.
 #	(The comment on each line shows the representation of
-#	the corresponding initial epoch in the usual
+#	the corresponding initial epoch in the usual 
 #	day-month-year format. The epoch always begins at
 #	00:00:00 UTC on the indicated day. See Note 5 below.)
-#
+#	
 #	Important notes:
 #
 #	1. Coordinated Universal Time (UTC) is often referred to
 #	as Greenwich Mean Time (GMT). The GMT time scale is no
 #	longer used, and the use of GMT to designate UTC is
 #	discouraged.
 #
-#	2. The UTC time scale is realized by many national
+#	2. The UTC time scale is realized by many national 
 #	laboratories and timing centers. Each laboratory
 #	identifies its realization with its name: Thus
 #	UTC(NIST), UTC(USNO), etc. The differences among
@@ -44,10 +44,10 @@
 #	by the International Bureau of Weights and Measures
 #	(BIPM). See www.bipm.fr for more information.
 #
-#	3. The current defintion of the relationship between UTC
-#	and TAI dates from 1 January 1972. A number of different
-#	time scales were in use before than epoch, and it can be
-#	quite difficult to compute precise timestamps and time
+#	3. The current defintion of the relationship between UTC 
+#	and TAI dates from 1 January 1972. A number of different 
+#	time scales were in use before than epoch, and it can be 
+#	quite difficult to compute precise timestamps and time 
 #	intervals in those "prehistoric" days. For more information,
 #	consult:
 #
@@ -60,7 +60,7 @@
 #
 #	4.  The insertion of leap seconds into UTC is currently the
 #	responsibility of the International Earth Rotation Service,
-#	which is located at the Paris Observatory:
+#	which is located at the Paris Observatory: 
 #
 #	Central Bureau of IERS
 #	61, Avenue de l'Observatoire
@@ -75,19 +75,19 @@
 #	local realizations of UTC.
 #
 #	Although the definition also includes the possibility
-#	of dropping seconds ("negative" leap seconds), this has
-#	never been done and is unlikely to be necessary in the
+#	of dropping seconds ("negative" leap seconds), this has 
+#	never been done and is unlikely to be necessary in the 
 #	foreseeable future.
 #
 #	5. If your system keeps time as the number of seconds since
 #	some epoch (e.g., NTP timestamps), then the algorithm for
 #	assigning a UTC time stamp to an event that happens during a positive
-#	leap second is not well defined. The official name of that leap
-#	second is 23:59:60, but there is no way of representing that time
-#	in these systems.
-#	Many systems of this type effectively stop the system clock for
-#	one second during the leap second and use a time that is equivalent
-#	to 23:59:59 UTC twice. For these systems, the corresponding TAI
+#	leap second is not well defined. The official name of that leap 
+#	second is 23:59:60, but there is no way of representing that time 
+#	in these systems. 
+#	Many systems of this type effectively stop the system clock for 
+#	one second during the leap second and use a time that is equivalent 
+#	to 23:59:59 UTC twice. For these systems, the corresponding TAI 
 #	timestamp would be obtained by advancing to the next entry in the
 #	following table when the time equivalent to 23:59:59 UTC
 #	is used for the second time. Thus the leap second which
@@ -102,7 +102,7 @@
 #
 #	If your system realizes the leap second by repeating 00:00:00 UTC twice
 #	(this is possible but not usual), then the advance to the next entry
-#	in the table must occur the second time that a time equivlent to
+#	in the table must occur the second time that a time equivlent to 
 #	00:00:00 UTC is used. Thus, using the same example as above:
 #
 #	...
@@ -114,11 +114,11 @@
 #	in both cases the use of timestamps based on TAI produces a smooth
 #	time scale with no discontinuity in the time interval.
 #
-#	This complexity would not be needed for negative leap seconds (if they
-#	are ever used). The UTC time would skip 23:59:59 and advance from
-#	23:59:58 to 00:00:00 in that case.  The TAI offset would decrease by
-#	1 second at the same instant.  This is a much easier situation to deal
-#	with, since the difficulty of unambiguously representing the epoch
+#	This complexity would not be needed for negative leap seconds (if they 
+#	are ever used). The UTC time would skip 23:59:59 and advance from 
+#	23:59:58 to 00:00:00 in that case.  The TAI offset would decrease by 
+#	1 second at the same instant.  This is a much easier situation to deal 
+#	with, since the difficulty of unambiguously representing the epoch 
 #	during the leap second does not arise.
 #
 #	Questions or comments to:
@@ -130,62 +130,62 @@
 #
 #	Last Update of leap second values:   11 January 2012
 #
-#	The following line shows this last update date in NTP timestamp
+#	The following line shows this last update date in NTP timestamp 
 #	format. This is the date on which the most recent change to
 #	the leap second data was added to the file. This line can
-#	be identified by the unique pair of characters in the first two
+#	be identified by the unique pair of characters in the first two 
 #	columns as shown below.
 #
 #$	 3535228800
 #
 #	The NTP timestamps are in units of seconds since the NTP epoch,
 #	which is 1900.0. The Modified Julian Day number corresponding
-#	to the NTP time stamp, X, can be computed as
+#	to the NTP time stamp, X, can be computed as 
 #
 #	X/86400 + 15020
 #
-#	where the first term converts seconds to days and the second
+#	where the first term converts seconds to days and the second 
 #	term adds the MJD corresponding to 1900.0. The integer portion
 #	of the result is the integer MJD for that day, and any remainder
-#	is the time of day, expressed as the fraction of the day since 0
+#	is the time of day, expressed as the fraction of the day since 0 
 #	hours UTC. The conversion from day fraction to seconds or to
 #	hours, minutes, and seconds may involve rounding or truncation,
 #	depending on the method used in the computation.
 #
-#	The data in this file will be updated periodically as new leap
+#	The data in this file will be updated periodically as new leap 
 #	seconds are announced. In addition to being entered on the line
-#	above, the update time (in NTP format) will be added to the basic
+#	above, the update time (in NTP format) will be added to the basic 
 #	file name leap-seconds to form the name leap-seconds.<NTP TIME>.
-#	In addition, the generic name leap-seconds.list will always point to
+#	In addition, the generic name leap-seconds.list will always point to 
 #	the most recent version of the file.
 #
 #	This update procedure will be performed only when a new leap second
-#	is announced.
+#	is announced. 
 #
 #	The following entry specifies the expiration date of the data
-#	in this file in units of seconds since 1900.0.  This expiration date
-#	will be changed at least twice per year whether or not a new leap
+#	in this file in units of seconds since 1900.0.  This expiration date 
+#	will be changed at least twice per year whether or not a new leap 
 #	second is announced. These semi-annual changes will be made no
 #	later than 1 June and 1 December of each year to indicate what
-#	action (if any) is to be taken on 30 June and 31 December,
+#	action (if any) is to be taken on 30 June and 31 December, 
 #	respectively. (These are the customary effective dates for new
 #	leap seconds.) This expiration date will be identified by a
 #	unique pair of characters in columns 1 and 2 as shown below.
-#	In the unlikely event that a leap second is announced with an
+#	In the unlikely event that a leap second is announced with an 
 #	effective date other than 30 June or 31 December, then this
 #	file will be edited to include that leap second as soon as it is
 #	announced or at least one month before the effective date
-#	(whichever is later).
-#	If an announcement by the IERS specifies that no leap second is
-#	scheduled, then only the expiration date of the file will
+#	(whichever is later). 
+#	If an announcement by the IERS specifies that no leap second is 
+#	scheduled, then only the expiration date of the file will 
 #	be advanced to show that the information in the file is still
-#	current -- the update time stamp, the data and the name of the file
+#	current -- the update time stamp, the data and the name of the file 
 #	will not change.
 #
-#	Updated through IERS Bulletin C45
-#	File expires on:  28 December 2013
+#	Updated through IERS Bulletin C46
+#	File expires on:  28 June 2014
 #
-#@	3597177600
+#@	3612902400
 #
 2272060800	10	# 1 Jan 1972
 2287785600	11	# 1 Jul 1972
@@ -222,10 +222,10 @@
 #	computed. Note that the hash computation
 #	ignores comments and whitespace characters
 #	in data lines. It includes the NTP values
-#	of both the last modification time and the
+#	of both the last modification time and the 
 #	expiration time of the file, but not the
 #	white space on those lines.
 #	the hash line is also ignored in the
 #	computation.
 #
-#h	abf85ecb f7dd8b73 964b20af 28692645 caa5fd81
+#h	1151a8f e85a5069 9000fcdb 3d5e5365 1d505b37