[Opendnssec-develop] Comparing times

[Rick van Rein]

Hello all,

As mentioned yesterday, I have an idea about how to compare timing, and
deal with comparisons of times.  It is a bit more complicated than the
plain approach, but it _does_ service the idea of a pushbutton, IMHO.

Specifications like 1y are vague -- is it 365 days or 366?  The core of
this question is that we sometimes need the higher value, and sometimes
the lower one.  We want to make sure not to make a choice that ends up
screwing with people's assumptions, or worse, that ends up screwing up
a domain's signed state.

The idea is simple -- we only use timing for comparisons.  Things like
"if I add a month, will I fall within the range of the year until
rollover"?  In comparisons, it is possible to take the cautious approach:

if t1 < t2:
	act_boldly ()

would become

if t1.maximum < t2.minimum:
	act_boldly ()

That is, t1 has both its maximum and minimum time added.  So if t1 is
specified as "1y + 1mo" its minimum would be 365+28 and its maximum
would be 366+31.

The funny thing is that this means that 1y <= 1y does not hold, nor does
1y < 1y.  This is the result of being cautious.


Now, how would this look in implementation?

Instead of keeping timing in an integer (counting days), it would be kept in 
a structure with a maximum/minimum field with those integers.  When parsing
timing, the fields would be filled as said above.

def addtm (t1, t2):
	return { max: t1.max + t2.max,
		 min: t1.min + t2.min }

def subtm (t1, t2):
	return { max: t1.max - t2.min,
		 min: t1.min - t2.max }

def less_equal (t1, t2):
	cmp = subtm (t1, t2)
	return (cmp.max <= 0)

def less (t1, t2):
	cmp = subtm (t1, t2)
	return (cmp.max < 0)

def equal (t1, t2):
	# Do we ever need this BTW?
	cmp = subtm (t1, t2)
	return (cmp.max == 0 and cmp.min == 0)

The advantage of this is that it makes it absolutely impossible for users
to assume things we cannot guarantee.  For example:
 - a year comprises of 14 months: 1y = 365..366 and 1mo = 28..31
 - a year comprises of 12 periods of 31 days: 1y = 365..366 and 31d = 31..31

This does not happen to answer to user's wishes for refreshes at set dates,
I know.  It does make it impossible to make false calculations based on
assumed period durations though.

The disadvantage is that this complicates calculations in a place where they
already require a lot of caution.  I can imagine that to be a driving force
in deciding to abandon this defensive coding approach.


Hope this helps,

Cheers,
 -Rick