Well, it should not (there is no timezone management at all in Ubooquity, all is done by the Java Virtual Machine running it).
But unless this oddity it has other unexpected side effects, the problem is not really worth investigating (I have never been able to reproduce it on my side).

Is the scan stuck on a specific files or is it progressing ?

If you want, send me the full log file :

 tom at vaemendis.net

No it should not. (excluding cases I may have overlooked)

Did you try stopping and restarting the server ? (you will not lose any data)

I have a task in my todo list to do some profiling, as there might be resource leaks.
But since it has not really been a problem so far, I kept postponing it (that and the fact that it's quite tedious a task).

From what I have seen, usually a few thousand dollars or euros.
That's not realistic (nor reasonable for a small project like Ubooquity).

Epub reader is on the way (though the way is quite long), and PDF.js integration is next.

It depends on the total memory available on your system as well as the version of the JVM you use.
It's printed somewhere at the beginning of Ubooquity log file if you want to take a look.

Yes, you can try that (for 500MB of memory, change it as you like):

nohup java -Xmx512m -jar Ubooquity.jar -webadmin </dev/null &>/dev/null &

I spotted an error in the script, probably the one that prevented you from using it, I'll fix it tonight. Done.

Unfortunately, apart from adding CPUs and RAM, there is not much you can do. Ubooquity was not designed to support heavy loads (the initial use case is a small home server or a NAS).

The only thing you can try (if you did not already) is to give Ubooquity more RAM to work with.
This is done with the -Xmx Java option.
If you use the script I provide, just uncomment this line (remove the "#") and change the value if needed:

#MEM_OPT=-Xmx512m