I am working on reporting function for roundup.
Interval math 
and printing seems a bit off and
is really making things 
difficult.

I will show the problems, and describe how I 
would
like it to work.

If I create an interval of 1 hour and 45 
minutes and
add it to another interval of 1 hour and 45 
minutes,
I get an interval of 2 hours and 90 minutes. This 
is
incorrect. It should be 3 hours and thirty minutes.
This is 
with roundup 0.5.3. Here is the test code:

from roundup 
import instance, 
date
a=date.Interval("1:45")
b=date.Interval("1:45")
c 
= a + b
print a
print b
print c

I get:

+ 
1:45
+ 1:45
+ 2:90

If I change the interval to 1d 20:10 I 
get:

>>> a=date.Interval("1d 20:10")
>>> 
b=date.Interval("1d 20:10")
>>> c=a+b
>>> print c
+ 
2d 40:20

it should be 3d 16:20.

Also addition of a 
negative interval doesn't work well
either.
>>> 
a=date.Interval("-1d 20:10")
>>> print a
- 1d 20:10
>>> 
print b
+ 1d 20:10
>>> print a + b
+ 2d 40:20
>>> print 
b + a
+

b+a = a+b and both should report 
00:00:00.

Also adding two negative intervals is an 
issue:

>>> print a; print b; print a+b
- 1d 20:10
- 1d 
20:10
+
Should be -3d 16:20.

Subtraction 
(multiplication and division) of intervals 
isn't
supported:
>>> a=date.Interval("1d 20:10")
>>> 
b=date.Interval("1d 20:10")
>>> print a-b
Traceback (most 
recent call last):
  File "<stdin>", line 1, in ?
TypeError: 
unsupported operand type(s) for -: 'instance'
and 
'instance'

print a/5
Traceback (most recent call 
last):
  File "<stdin>", line 1, in ?
TypeError: unsupported 
operand type(s) for /: 'instance' and 'int'

For summary 
reports (average intervals) division is
required.

Also the 
string form of intervals isn't constistent in form.

>>> 
b=date.Interval("00:00"); print b
+

should print '+ 
00:00:00'.

I claim that all intervals should be presented 
as
     (+|-) [y] [d] hh:mm:ss
Where the number of days and 
years (365d 6h/ year)
are shown only if they are not 
zero.

I suggest that hours, minutes and seconds always 
be
shown because their interpretation is not based on 
a
label (y or d) but on position so there is an ambiguity
in 
displaying an interval like: 10:20
Is that
   00:10:20
or
   
10:20:00

By displaying all three entities, the ambiguity 
is
resolved for the viewer. Also it makes manipulation
of the 
interval easier. If the programmer wishes to
remove the number 
of seconds from an interval, it can
easily be done by removing 
the last three characters.
Currently, you have to determine if 
the interval has any
seconds and remove them if 
present.

Some alternate function may be provided to 
print
intervals that use weeks. The default code should 
be
able to handle week intervals (being equivalent to 
7
days/week).

Months should not be created unless 
the original
interval incldues months. Months should be rolled 
into
years at a rate of 12 months/year. Days should not 
be
rolled into months unless the user defines the 
ratio
between days and months. E.G.

   date.Interval('1y 
2m 3d 4:50:10", 30.44)

would result in 30.44 days/month. 
Or

  date.ConvertInterval("1y 45d 4:10", 30.44)

as 
an alternate way of dealing with it.

One way to handle most 
of this is to convert intervals
to  integer seconds and use regular 
integer arithmetic on them and the convert back to component 
form.

-- rouilj

Logged In: YES 
user_id=6405

Gawd the sf tracker is horrible. I'm sure your original text wasn't so badly 
formatted :) 
 
The addition / subtraction code definitely needs some attention, thanks for 
pointing that out. Overflows in time calculations should be handled, up to 
the day level. Day overflow cannot be handled reasonably into months 
without some programmer intervention. Certainly not through some default 
ratio like 30.44 - that would produce strange results indeed. Off the top of 
my head, I can't think of a situation where a user would _want_ day overflow 
to affect months. 
 
I agree with your comment about time representation ambiguity. 
 
Division of intervals is a strange one, and I'm not sure it's so common as to 
require the major change to the way intervals work to support. I don't 
believe that month intervals may be dismissed so easily. They're a useful 
quantity to be able to define. Converting months into some number of days 
will not do. Perhaps an alternative is to be able to extract the number of 
seconds for an interval (supplying the number of days/month (default 
30.44) and days/year (default 365.4)) which may then be manipulated by 
division etc. and supplied back to the interval code (again with the 
conversion ratios). This then makes it explicit that funny business is going 
on with conversion ratios, and the current internal representation and 
behaviour is unaltered (short of the addition/subtration bugs ;). 
 

Logged In: NO 

Here is the spec I have been noodling with feel free to tell me
what is 
missing or what I haven't thought of. Algebra is but a
distant memory 
to me at this point.

'I' stands for interval 'N' stands for number (real 
or integer),
'D' stands for date. -> is read as creates. The number is 
just
an instance specifier I1 - I2 interval 1 minus interval 2 
etc.

The interval package should support the following 
operations
and use cases:

   I1 + I2 -> I3  - add two intervals

   
I1 - I2  -> I3  - subtract two intervals if I1 > I2 the result is
                       a positive interval 
that will result in a future
                       time when added to a date. Otherwise the
                       
result is a negative interval that will result
                       in a time in the past when 
added to a date.
                       Also,  (I1 - I2) + (I2 - I1) = 0 should be true.

   I * N -> I    - 
multiple an interval by a number. I expect this
                 to take 14 hours and 10 
minutes. so I can do
                 4 of them in 4*(14:10)

   I / N -> I   - divide an 
interval by a number. The average
                    time it took to do this was 
(I1+I2+i3+I4)/4.

  I1/I2 -> N  - Division of two intervals. Used for 
calculating
                   percentage of time in a given state. E.G. I1 is
                   the 
amount of time in the open state. I2 is
                   the amount of time it was in the 
open and
                   testing states. The ratio gives us the amount of
                   time 
spend working compared to time to close.

  D + I -> D  what date time 
is it in 1 day 4 hours

  D - I -> D    what date was it 1 day and 4 hours ago
                   
Also D + (-I) = D - I. where -I is a negative
                   interval.

I claim that only 
I+I should be supported for intervals that
include months since there 
is a fixed number of months per
year and we can round up. If we can use 
some heuristic to
allow carrying from a month into days, then I -I and 
other
operations are allowed.

If we can live with this 
restriction, then the date math needs
to be able to produce the 
difference of two dates without the
months component using days 
instead, which should be
doable since there is a fixed number of days 
between any
two dates.

-- rouilj

Logged In: NO 

Actually I will be using division quite heavily in the reporting
app I  am 
working on.

    Think average amount of time tickets were 
*

insert favorite time for your start:
    new to resolved, open to 
resolved, open to testing
    open to testing minus 
stalled

etc.

For interval/interval division, I am looking at a 
metric of:

  total amount on time spent in non-working states (hold, 
stalled) divided by total time ticket is open (from first open->last 
resolved)

I was looking at the perl 
module:

http://hacks.dlux.hu/Class-
Date/manual.html#months_and_years

for some ideas and 
issues.

-- rouilj

Logged In: YES 
user_id=6405

OK, I've