[LEAPSECS] [time-nuts] Leap Quirks

[Rob Seaman]

M. Warner Losh wrote:


> And how are leap seconds represented in this convention?


They aren't.  The choice of the underlying time or angular scale is an  
orthogonal issue.

Begin aside:

To comment further, the apparent separate fields of sexagesimal  
fractions are not generally not constrained, e.g.:

	cl> = 12:34:56
	12.582222222222
	cl> = -12:34:56
	-12.582222222222
	cl> = 12:34:56.789
	12.582441388889
	cl> = 123:456:789
	130.81916666667

("cl>" is the command language prompt.)

It will throw a syntax error if the hours/degrees or minutes field is  
not an integer, or if the minutes or seconds fields are negative.   
Other than that, minutes or seconds can overflow to your heart's  
content.  (Just like my microwave at home.)

For example:

	cl> = 12:34:59
	12.583055555556
	cl> = 12:34:60
	12.583333333333
	cl> = 12:35:00
	12.583333333333

Is this correct for a leap second?  Rather, it isn't representing a  
leap second at all.  The point of leap seconds is to jump outside the  
angular paradigm and correct an alignment issue at a fine enough  
resolution to be ignored for most purposes.

If some application needs to know about leap seconds, the data type of  
some parameter would be left as a string rather than a real and the  
application (or system function) would juggle the characters directly.

Common sense constraints are applied through the general purpose  
formatting library, e.g.:

	cl> printf ("%h\n", 12:34:60)
	12:35:00.0
	cl> printf ("%h\n", 12:59:60)
	13:00:00.0

Again, if there is some need to represent a leap second within the VOS  
or application, this would be tailored to the purpose.  Also, limits  
on the number of hours or degrees are not implicit in the  
representation, but explicit in the application.  Angles are sometime  
constrained to fall within 0:00:00 to 359:59:59.999, but also  
sometimes from -90:00:00 to +90:00:00, similarly with hours being  
packed into days.

Of course, the point of this is to permit arithmetic that treats each  
angle as a single value, rather than an awkward triple of integers (or  
two integers and a real):

	cl> printf ("%h\n", 12:34:59 - 01:23:45)
	11:11:14.0

One could imagine extending this to ISO-8601 date/time pairs, but it  
has never become a priority.  I have some purpose-built functions for  
my applications that need to handle ISO strings.  The date/time  
primitives in the VOS pass two separate values in typical field  
arrangements.  (The pair is atomic, of course.)

Loosely constrain input.  Explicitly constrain output.

End aside.

Rob