It's just the way I've done it, note Dti will always be positive in my code and therefore adc_last=adc_last+Dti....charging, whilst adc_last=adc_last-Dti.... discharging.
But you are correct, integers/longs and FP's carry sign, I will modify my code forthwith and save some bytes.

This is exactly one of the points where the form

Adc_out_new = ( 1 - (t_sample / fil_time) ) * Adc_out_old + (t_sample / fil_time) * Adc_in_new 

of the equation has a big advantage over the other form: The above also works with unsigned numbers. (And the '51 is a lot better with unsigned integers than with signed integers). None of the partial results of the above equation will be negative, provided that your Adc_in_new is positive (which depends on the ADC you are using - for this reason, some of them do use numbers with an integer offset, i.e. 0x8000 would be a "zero" mesurement, 0x0000 a "negative saturation" and 0xFFFF a "positive saturation").

Actually, if memory serves me correctly, I was using it with a SAR adc which had a positive common mode voltage, so I was using word(+16bit) data types and biasing half way on a 16 bit word, thus I didn't have an automatic sign.

A DC offset can be subtracted before or after a lowpass filter, provided that you know the DC gain of the filter (should be 1 in most cases). So, you can feed the "unmodified" ADC values into the filter without having to care about the offset at that point.

You have got to admit, that makes more sense, for me at least anyway, thanks for that,

Depends. Back at the university, I had classes in both simulation engineering and signal processing, and the professors made a point of explaining why some things that are good for one of these (4th order ODE solvers are nice for precise simulations ...) will fail miserably when used on the other (... but 4th order ODE solvers require results at fractions of the step size, which you don't have in a signal processing application). Likewise, you won't see a lot of z domain stuff when you're designing simulations, since you're going to do stuff in the simulations (change the "sampling rate" / simulation step size, even dynamically while the simulation is ongoing, for example, or dealing with nonlinear equations) which the z domain analysis is fairly badly suited for.

It's all a matter of choosing the right set of tools for the job at hand.