Dave Rolsky said: > The more I think about this the more I'm convinced that the idea of > datetime subtraction producing something other than seconds is a > convenient fiction. Similarly, date subtraction producing something other > than a count of days is full of potential bugs.
I agree .. let DateTime::Duration just result in these two units so that: Date - Date = d Days Time - Time = s Seconds DateTime - DateTime = (Date - Date) + (Time - Time) = d Days + s Seconds Of course, then there's the normalization question: 2005-09-10T12:54 - 2005-09-09T12:57 = a) 1 days, -180 seconds b) 86397 seconds Previously I campaigned for no mixing of negative/positive values in durations, but now I'd prefer the first option. That way, DST won't matter so much. On DST change-over I can still add 1 day, -180 seconds to 12:57 and end up on the next day at 12:54. With the second option I'd end up at 1:54 or 11:54. I guess the first option is the equivelent of the 'Local' arithmetic and the second is the equiv of UTC arithmetic. If we limit durations to these two units (days, seconds) then everything else can be done in DT:F:Duration... You have 30 days, your base is November 1st, the number of 'months' in this duration is 1. It's December 1st, there's zero months.. I'm not campaigning to see a Duration limited to these two units, just a substraction resulting in them. A duration can have 3 months, 1 hour. DT:F:Duration will be able to do a 'normalize' without any parsing/formatting which will mean that our 30 days from Nov 1st can be turned into a Month if that's what you tell DT:F:Duration that's how you want it. Cheers! Rick Measham
