| Age | Commit message (Collapse) | Author |
|---|
|
It was ovious that this is broken when you try to round "0s" to
second-level granularity, and you end up with "1s". The problem comes
from the fact that we use the integer divison when checking whether we
should round up or down, but then also use strict inequality.
To fix this, we now also round down if the second_offset is equal to the
halfway point (which in the case of second-level granularity is 0).
|
|
We basically do the same hacky trick in two different places, so maybe
we should put it into a separate function, test it, and if a better
implementation arises, swap it.
|
|
|
|
|
|
|
|
It turns out that the mt:TourStartTime is also given in UTC, and
therefore cannot be used to get the timezone offset. The problem was
that my local computer's timezone was the same as the tour timezone, so
by the magic of Python's datetime.datetime.fromtimestamp (and the date
CLI util), I did not notice that the timestamp actually represents UTC.
Sadly, it currently looks like there is no way to extract the time zone
from a MyTourbook export.
|
|
|
|
|
