<div dir="ltr">I realized that the date 01/01/1900 was out of range only when Salva told me that the "fake" dive was indeed present in the list, albeit not in the expected order. As I have already explained to Salva the only reason for having that "fake" dive was to use it as a template for new dives in SmartTrak. The "template dive" has no meaning for subsurface. Salva wrote me not to ditch SmartTrak, at least not to do that right now. The template dive is handy for logging new dives in SmartTrak, since it provides default data for suit and tanks in new dives. Therefore I do not want to delete it.<div><br></div><div>I have just changed its date to 01/01/1990 and it is now perfectly OK with SmartTrak and with subsurface. The wrong ordering of dives for dates older than 1970 (beginning of the UNIX epoch) is not IMHO to be considered as a bug. Nobody was even thinking to an electronic dive log before 1970. In the sixties and in the seventies I was using a paper logbook. i would like to find it, but I have no idea about its physical location: I cannot find it with recoll ...</div><div><br></div><div>As far as I am concerned changing the date of the "fake" dive is the solution of the issue. I have always "suspected" that Linus Torvalds is a perfectionist and I am therefore sure that the issue of dates older than 1970 will be soon fixed anyway. The question of signed and unsigned integers has always been a major "bug generator". I remember of having once put a BGT instruction ( Branch if Greater, for signed 16 bit integers) in place of a BHI instruction (Branch if Higher, for unsigned 16 bit integers). It was a piece of assembly code for a DEC PDP 11 of the Jurassic age. The result was a powerful high frequency hydraulic actuator completely out of control and a severe damage to the machinery. The mishap happened after several years of flawless operations, when the addition of a "nice-to-have" Fortran routine resulted in the upwards shift of a part of an integer array beyond physical address 32767. The error in the position of the "fake" dive in the list has been definitely LESS PAINFUL !</div><div><br></div><div>Very best regards.</div><div><br></div><div>Alessandro</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 8:55 PM, Linus Torvalds <span dir="ltr"><<a href="mailto:torvalds@linux-foundation.org" target="_blank">torvalds@linux-foundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Feb 17, 2017 at 11:52 AM, Alessandro Volpi <<a href="mailto:volpial@gmail.com">volpial@gmail.com</a>> wrote:<br>
> In my last message I said that the AppImage was working in Fedora 24, except<br>
> for some details related to font issues. That is not correct. In practice<br>
> the AppImage succeeds in producing good dive list and dive profile plots.<br>
> The problem is that the main menu lists are empty !  Clicking on the empty<br>
> space the required action is indeed executed.<br>
<br>
Ok, I can't help you with the UI parts (they are likely about some<br>
Appimage issue anyway). But:<br>
<br>
> I have also changed the date of the fake dive from 01/01/1900 to 01/01990.<br>
> Now the fake dive is the first of the list, as it should be .<br>
<br>
So we don't handle dates before 1904 correctly (why 1904? It's a<br>
leap-year issue: the year 1900 is "odd" and is *not* a leap-year<br>
despite the usual divisible-by-four, so our internal date handling is<br>
basically limited to 1904..2099 because it takes shortcuts).<br>
<br>
But to make matters worse, the divelist sorting was broken for<br>
anything before 1970 (which is our base "epoch"). It used an unsigned<br>
64-bit comparison for sortng, it should be signed.<br>
<br>
I'll make a pull request for Dirk, because we *should* allow dives before 1970.<br>
<br>
But in the meantime, yeah, use 1970+ as a base date for testing.<br>
<span class="HOEnZb"><font color="#888888"><br>
              Linus<br>
</font></span></blockquote></div><br></div>