Originally Posted by RobTrew
Probably worth experimenting with ofoc_year_zero in line 728 - particularly the value and handling of int_zone - there must be a simple oversight in the logic – let me know if you spot it.
You should be able to make some adjustments around lines 147-162 and their interconnections. (# DEFAULT DATA TO EXPORT)
I've found a solution, though it feels like a hack. Here's my reasoning: the code
in lines 728-732 for ofoc_year_zero() are actually correct. The error is when you use it, for instance 680-683
if (int_start is not None):
str_line = ''.join([str_line, 'start=\"', \
time.strftime('%d%m%y %H%M%S', \
time.gmtime(year_zero + int_start)), '\" '])
I think you should be adding int_zone there to the start date , int_start. But that would be a messy change as it would have to be done in several places.
So my solution is to change 732 to add in the time-zone twice, so it changes from
return int(time.mktime(time.strptime("1 Jan 01", "%d %b %y")) + int_zone)
return int(time.mktime(time.strptime("1 Jan 01", "%d %b %y")) + (2*int_zone))
If I am right I suppose it would be good to rename year_zero to something like year_zero_with_extra_timeChange so there's no confusion.
I'm a bit cautious with all this as there's quite a bit of the code that I really don't understand, and it involves variable year_zero. But I can say that this simple change seems to solve my problem and hasn't created any others, at least not that I've found with my test-cases.
I'll work on getting the non-active tasks on another day.