An integer field, every record containing the same, positive superdate, gives the wrong value on `Minimum`

, either via Analyze menu or via `aggregate(`

. `Maximum`

gives correct values both ways. I discovered this with 1331 records of just 3599814258 resulting in a ‘minimum’ of 2147483647, but suspect the problem is wider than that in scope. I exported the data as text then reimported it into a new database, changed the field to integer and got the same results; ruling out something goofy with my original database.

If I fill those records with -3599814258 then maximum returns -2147483647 and minimum works correctly.

If there are any values less than 2147483647, minimum will return the correct value, and if there are any values greater than -2147483647, maximum will return the correct value.

In my experimenting I find in an integer field anything over 2147483647 returns 2147483647. If you change the field to Float you are not restricted to this limit.

It’s probably significant that 2147483647 is the maximum value for a 32 bit integer.

Holy quadruple underbyte!

Apple’s code apparently confused me, and I picked the wrong constant. So minimum won’t currently work if ALL values are larger than 2147483647 (as David already stated). I haven’t tested this yet, but I think that maximum probably doesn’t work if all values are more negative than -2147483647. Should be an easy fix (famous last words).

Bug remains, although listed well at bitbucket over three years. I guess not many use superdates to find oldest and newest values on a series of computer record time stamps as others aren’t complaining.

Until this gets formally fixed a work around is sometimes available. The 32bit max corresponds to the superdate on 1/19/1972. Double that max to 2/6/2040. If all ones dates fall between then:

`aggregate({yourSuperDateField-2147483647}, "minimum")+2147483647`

will give the correct minimum superdate value. So long as your dates cover less than a roughly 78 year range similar adjustments can shift min/max aggregations to where they’ll work.

Interestingly this bug does not affect minimum values obtained via `summarytable(`

Thanks for the nudge – I have now fixed this bug.

The summarytable( function was not affected by this problem because it always uses floating point calculations, not integers. The bug only affected integer calculations.