Time Tracker Project
The way you're handling add "modes" is a little clunky. It seems that only one of _add or _sub should ever be true at the same time. By making these two separate variables, you need to make sure that invariant is maintained everywhere. You've definitely helped make sure it's safe by using the add and sub functions, but those are band-aids on an awkward design.

The easiest way to simplify this is just to have one variable. Something like:

_is_adding = True


If this is true you're adding, if it's not, you're subtracting. Now find_mode can be much simpler:

def find_mode():
    return 0 if _is_adding else 1


And add and sub simply becomes:

def add():
    global is_adding
    is_adding = True

def sub():
    global is_adding
    is_adding = False


Although,



I think you're overusing globals here. In some cases, like UI callbacks, they may be the cleaner (but not only) option. find_mode for example though itself does not need to rely on globals. If you can cleanly pass data in instead of relying on globals, you should. I'd change it to:

def mode_number(is_adding: bool) -&gt; int:  # I added some type hints in and renamed it
    return 0 if is_adding else 1

. . .

mode = simple_mode(mode_number(_is_adding))


The gain here is incredibly small because of how simple the functions involved are. In general though, it's a good habit to get into. Functions that explicitly take as arguments all the data they need, and return all the data that they produce are much easier to understand. 

simple_mode and find_mode are kind of odd though if you think about them. Why translate add/sub into a number just to then translate it back to "Add"/"Subtract"? I think this makes more sense:

def format_mode(is_adding: bool) -&gt; str:
    return "Add" if is_adding else "Subtracting"

. . .

mode = format_mode(_is_adding)




I think simplify is a bad name for a function. What's it "simplifying"? If I'm writing a function that turns something into a string, I usually call it format_* (although that's just a habit of mine). Give some description though. I'd probably call it format_time, and adding some simple type hints make the types clearer:

def format_time(_time: int) -&gt; str:
    return time.strftime('%H:%M:%S', time.localtime(_time))


I'm not sure I 100% agree with calling the parameter _time to avoid the name collision, since a prefix _ typically means a "private" attribute, but I can't offhand think of a better name either, since the function is pretty broad in its purpose.



end_time-start_time-(-2211688800))


What the heck is -2211688800? That seems to offset the date by 70.1 years. Whatever it's purpose I see two problems:


If that's meant to offset today's date to reach a certain format, it'll be outdated from the second it's written. You should see if you can automate the creation of that number.
Magic numbers, especially large unusual like that should be named. Something like:

TIME_OFFSET = 2211688800

. . .

end_time - start_time - (-TIME_OFFSET)



Also, x - (-y) is the same as x + y (unless x and y are some custom type with odd math laws). It should just be:

end_time - start_time + TIME_OFFSET




The Flask import seems to be unneeded.