From 4d212a9ddc627e73d4930729b88224e53b6d3991 Mon Sep 17 00:00:00 2001
From: Tim Parenti <tim@timtimeonline.com>
Date: Wed, 9 Jul 2014 17:31:22 -0400
Subject: No leap second on 2014-12-31.

* leap-seconds.list: Per IERS Bulletin C48 (2014-07-07), no leap second on
2014-12-31.  Update file from NIST.
---
 leap-seconds.list |  132 +++++++++++++++++++++++++++-------------------------
 1 files changed, 69 insertions(+), 63 deletions(-)

diff --git a/leap-seconds.list b/leap-seconds.list
index 607fa7d..0980e7b 100644
--- a/leap-seconds.list
+++ b/leap-seconds.list
@@ -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.
@@ -20,17 +20,17 @@
 #	ignore the complexities of the time scales that were
 #	used before the current definition of UTC at the start
 #	of 1972. (See note 3 below.)
-#	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 each line is 
-#	valid from the indicated initial instant until the 
+#	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 each line is
+#	valid from the indicated initial instant 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
@@ -38,7 +38,7 @@
 #	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
@@ -49,10 +49,10 @@
 #	by the International Bureau of Weights and Measures
 #	(BIPM). See www.bipm.fr for more information.
 #
-#	3. The current definition of the relationship between UTC 
-#	and TAI dates from 1 January 1972. A number of different 
-#	time scales were in use before that epoch, and it can be 
-#	quite difficult to compute precise timestamps and time 
+#	3. The current definition of the relationship between UTC
+#	and TAI dates from 1 January 1972. A number of different
+#	time scales were in use before that epoch, and it can be
+#	quite difficult to compute precise timestamps and time
 #	intervals in those "prehistoric" days. For more information,
 #	consult:
 #
@@ -63,31 +63,34 @@
 #		of Time," Proc. of the IEEE, Vol. 79, pp. 894-905,
 #		July, 1991.
 #
-#	4.  The insertion of leap seconds into UTC is currently the
-#	responsibility of the International Earth Rotation Service.
+#	4. The decision to insert a leap second into UTC is currently
+#	the responsibility of the International Earth Rotation and
+#	Reference Systems Service. (The name was changed from the
+#	International Earth Rotation Service, but the acronym IERS
+#	is still used.)
 #
-#	Leap seconds are announced by the IERS in its Bulletin C
+#	Leap seconds are announced by the IERS in its Bulletin C.
 #
 #	See www.iers.org for more details.
 #
-#	All national laboratories and timing centers use the
-#	data from the BIPM and the IERS to construct their
-#	local realizations of UTC.
+#	Every national laboratory and timing center uses the
+#	data from the BIPM and the IERS to construct UTC(lab),
+#	their local realization 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 +105,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 equivalent to
 #	00:00:00 UTC is used. Thus, using the same example as above:
 #
 #	...
@@ -112,13 +115,16 @@
 #	...
 #
 #	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 
+#	time scale with no discontinuity in the time interval. However,
+#	although the long-term behavior of the time scale is correct in both
+#	methods, the second method is technically not correct because it adds
+#	the extra second to the wrong day.
+#
+#	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,64 +136,64 @@
 #
 #	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 1 January 1900, 00:00:00. The Modified Julian Day number 
-#	corresponding to the NTP time stamp, X, can be computed as 
+#	which is 1 January 1900, 00:00:00. The Modified Julian Day number
+#	corresponding to the NTP time stamp, X, can be computed as
 #
 #	X/86400 + 15020
 #
-#	where the first term converts seconds to days and the second 
-#	term adds the MJD corresponding to the time origin defined above. 
-#	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 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 
+#	where the first term converts seconds to days and the second
+#	term adds the MJD corresponding to the time origin defined above.
+#	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 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 the origin at the instant
-#	1 January 1900, 00:00:00.  This expiration date will be changed 
+#	1 January 1900, 00:00:00. 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 C47
-#	File expires on:  28 December 2014
+#	Updated through IERS Bulletin C48
+#	File expires on:  28 June 2015
 #
-#@	3628713600
+#@	3644438400
 #
 2272060800	10	# 1 Jan 1972
 2287785600	11	# 1 Jul 1972
@@ -224,10 +230,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	9195bac3 a050810e e85fc815 e752446a 76ade206
+#h	a4862ccd c6f43c6 964f3604 85944a26 b5cfad4e
-- 
1.7.9

