Ho letto la documentazione di IBM e mi sono accorto di una nota che hanno messo che forse è proprio quella che rompe le scatole nel tuo caso.
La documentazione che ho letto la trovi qui:
https://www.ibm.com/docs/en/i/7.4?topic=functions-find-duration
Alla fine della spiegazione, fa presente che:
In order to determine the valid duration keywords, the following rules apply:
- If argument-1 or argument-2 is a date item, the duration specified must be consistent with a date.
- If argument-1 or argument-2 is a time item, the duration specified must be consistent with a time.
- If the returned value is not an integer, it is truncated. For example, the duration between March 17, 1997 and May 2, 1997 is 1.5 months. Since FIND-DURATION only returns an integer the .5 would be truncated, and the actual value returned would be 1.
- PICOSECONDS duration can only be requested when argument-1 and argument-2 are timestamp items.
A parte che spiega bene il troncamento (cosa che può tornare comodo per i tuoi calcoli), non vorrei che il campo di tipo TIMESTAMP venga considerato come "time", per cui non ha senso parlare di giorni/mesi/anni ma solo di ore/minuti/secondi.
In pratica:
- Se passi due date, allora puoi usare YEAR, MONTH, DAY perchè sono delle frazioni di date
- Se passi due timestamp (considerati come orari), allora puoi usare HOUR, MINUTE, SECONDS perchè sono frazioni di ora. Non puoi però usare YEAR, MONTH, DAY perchè non sono orari
In questo caso, dovresti farti dare la differenza in minuti e poi farti tutti i calcoli a mano.
In fin dei conti, nel tuo caso, credo anche che sia la cosa migliore: l'assicurazione è precisa al minuto, quindi tanto vale convertire tutto in quell'unità di misura e fare i calcoli.