time-period-normalize

[acarrico]

I didn't notice a function to normalize time periods, so given 61 minutes, you'd get 1 hour, 1 minute, but given 48 hours, you'd still get back 48 hours. Is this a missing feature, or is there a semantic issue (or am I blind)?

[97jaz]

There is no such function currently. It could be done for time periods (though note that it could not be done for date periods). Of course, it can only be done for time periods, because gregor doesn't acknowledge the existence of leap seconds.

Can I ask what your specific use case is? Maybe there's another way of achieving the same goal?

[acarrico]

Sure. I parse an org file to get time stamps created with at-time, and use period-between to get time-periods, add those up with +time-period.

[acarrico]

Once I use period-between, I'm thinking about an absolute time period, rather than a calendar start and end point. Sorry if I'm rehashing your whole design experience here in the issues.

[97jaz]

You could do this by using a combination of time arithmetic and period-between. And, yes, I realize that you're already using both. But let's say you've added together your periods, and you have a period p of 61 minutes, but what you'd like us a period of 1 hour and 1 minute. You could get that with:

(define p (minutes 61))
(let ([t (now)])
    (period-between t (+period t p) '(hours minutes)))

(Note that t doesn't need to be (now); it can be any arbitrary datetime-provider.)

I think this is a reasonable definition of time-period-normalize:

(define (time-period-normalize tp [units time-units])
  (define epoch (datetime 1970))
  (period-between epoch (+period epoch tp) units))

Without a contract, you could use this on arbitrary periods, but, as I pointed out in my previous note, that would be a bad idea, since the behavior would depend on the function's choice of epoch.

[97jaz]

@acarrico Did my previous post help? Do you want to keep this issue open?

[acarrico]

Before I opened the issue I did a version that rolled seconds and minutes up to hours. I stuck with that. It doesn't really make sense to gauge it against a point in real time in this context: the periods are produced from two real time points and therefore already account leaps/daylight savings/etc. in the difference. Really this is just a suggestion that those semantics would be generally useful, so it might make a good utility.

[97jaz]

@acarrico Yes, I think this could be useful as well. I'm going to reopen this.