Make an integer field in which all the records have negative values. Choose Maximum from the Analyze menu and the value returns zero, rather than the least negative integer value in that field. Minimum works ‘properly’ on that field and both work properly on a field with all positive values. I haven’t tested further than that.
Oops, I forgot to put this in the Panorama X category.
Yup, I can duplicate that, and the problem occurs for both integer and floating point fields.
I discovered this working on a field of superdates transferred over from Pan6 and noted the difference between Pan6 and PanX’s superdate formats, which I presume is a consequence of your ending their old 2040 end date. Which date certainly seems more imminent now than when you first introduced the superdate concept. PanX uses seconds since the 1/1/1904 beginning date and thus has positive values. I suppose increased precision allows larger integer values thus extending the future range. Pan6’s documentation claimed it used seconds after 1/1/1904, but it actually used the seconds before the 2040 end. PanX’s various superdate using functions seem to handle both positive and negative superdates properly, but only creates positive ones. The one trouble I conceive would be computing time differences, between a mixture of new and carried over old values, would give unexpected results. Converting the old to text with superdatesecondsstr(, then back to a new positive superdate number would avoid that. Unless there is more magic in your changes than I understand, you might want to mention this in the documentation.
Actually, it does in fact use seconds after 1/1/1904, as 32 bit unsigned integers. However, Panorama’s integer fields are signed integers, which means that half the possible values are interpreted as negative numbers. The negative half are those that begin with a one bit. In Panorama 6, superdates before 1/19/1972 at 3:14 AM appear as positive numbers in an integer field, those after that date and time appear negative. The 2040 maximum was simply the limit on a 32 bit unsigned integer.
Panorama X uses 64 bit integers. They won’t roll over to negative values for another 500 trillion years or so, and it will take twice that long for them to max out completely.
This would work in most cases (in the U.S.) but there would be issues with dates that are more than 50 years old, and date formats in other countries that don’t match ours. An alternate formula that avoids date format issues would be to use a formula of
superdate(regulardate(«»),regulartime(«»))
in a formula fill.
Thanks for the fun trivia on those old ‘negative’ superdates actually being positive ones, just being displayed negatively because the fields were set to interpret the highest bit as +/-. I figured increased computer power allowed larger integers and thus a longer time scale. But I hadn’t thought through the implications. If a cosmologist wants to model the end of the universe in PanoramaX, Superdates are now up to it.
And many thanks for the better conversion formula. As I gradually retire Pan6 dbs, importing their records into PanX successors, I’ll run that on my superdate fields. I’ve started a utility stack that does bulk 6 to X imports/Replaces/MatchingFields based on a list of dragged paths. I’d planned on expanding it to copy over the current value of any permanent file globals. This is another automatable add-on to make my transition easier once my PanX code is working and reasonably optimized.
I could have saved myself some time if I had refreshed my browser window before I duplicated the effort of coming up with the same fix! At least now I’m sure my solution is correct!
I have to confess that I didn’t quite think all of this thru back when I was coding this, or I would have added it to the documentation. I’ll do that now, and probably add a statement that makes this fix easier. Unfortunately, there is no way to do this completely automatically when transferring from Panorama 6 to X, because there is no way to positively identify that a field actually contains SuperDate’s as opposed to any other integer value.
Actually, in Panorama X the negative values can’t be used – so 500 trillion years or so is the limit. If the regulardate( function sees a negative value, it essentially interprets that as seconds before 2040, as John surmised (actually, it just strips off the sign bit). So if you don’t run the transformation formula, the superdates originally from Panorama 6 will still display the correct values. The only problem is, as John suggested, directly comparing a SuperDate entered in Panorama 6 with a SuperDate entered in Panorama X, or performing math between them (seconds from A to B). But if you compare regulardate(A) to regulardate(B), that will work, even if A was created in 6 and B in X or vice versa. How’s that for a tongue twister.
Unless I’m misunderstanding you, that isn’t necessary. Panorama X already copies over the current value of any permanent variables in a Panorama 6 database.
I must have hit a stray key on the calculator or something. It’s more like 290 billion, so the end of the universe may be out of reach but “the end of the world as we know it” might still be in range.
Then current permanent variable values were copied over when my Panorama X versions were created. But some 6 code had to be tweaked to fit changed X syntex and I had a lot of old code I’m choosing to rewrite to run more efficiently. Meanwhile I keep running my old 6 working versions, on which those permanent variables may change. So I periodically update the records and the permanent variables in X versions under development to that of the now current 6 versions. Happily this can be done programmatically. Mass import of records from 6 to X works slick. I’ve drafted, but not yet tested, additional code to update the variables.
You correctly point out neither 6 nor X can internally differentiate fields containing superdates from other integer fields. But I think all of mine were named “SD whatever” so I should be able to identify and update them automatically.