| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Depending on the Python version, this might raise an error: Before 3.8,
mimetypes.guess_type could not deal with a pathlib.Path, and only
accepted a string. guess_type is called internally by FileResponse, so
to make sure we don't run into errors, we stringify the path before
passing it to FileResponse.
|
|
|
|
|
|
|
|
Even though the change is "relatively simple", it does add quite a bit
of stuff since now we do need metadata in the database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is just debug logging information, but accessing self.id for an
object that is not in the database raises an error, because self.id is
None and %d cannot format None. In this case, we simply use -1 as id
instead.
|
|
|
|
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.
|
|
|
|
|
|
|
|
This is used for the README and the CHANGELOG, as they are read during
setup.py. If we do not include them, building a source distribution will
fail.
|
|
|
|
This is for example useful for the template inputs. They should not be
sent due to the "disabled" attribute, but we never know what browsers
are doing, therefore we stay defensive. The test case already has to do
extra steps to prevent those from being sent.
|
|
|
|
A few lines above the change, we set track.date to a timezone-aware
date. We shouldn't overwrite it with a naive datetime right after.
|
|
The big button with the large padding looked kind of silly, so now the
button is slimmer and the text is actually centered.
|
|
|
|
|
|
|
|
|
|
For the most part, we want to know the instant of when something
happened. To stay consistent, we save everything as UTC. For internal
things, this doesn't really matter - we just need to know the timezone
to be able to compare the values (like "is the upload older than 5
days").
For user-facing things (like comments), we still want to store the UTC
time and then convert it to the user's preferred timezone on display.
|
|
|
|
|
|
After the change to pyramid contexts, this parameter is now track_id.
This was missed back then.
|
|
|
|
Sometimes, the GPX itself does not have a name set, but the single
tracks might have.
|
|
|
|
The other code kinda assumed that we can turn the resource path into a
package by replacing the slashes (path separators) with dots. That
turned out to not really work in the end, especially if the resource
subfolders don't have a __init__.py in there.
This uses the .files() API (available in Python 3.9 and backported in
importlib_resources) to better handle folders in the resources.
|
|
|
|
Those things are not really a configuration thing that changes, rather
they are part of how the code of the application works. As such, it
doesn't make too much sense to require those configuration values.
Instead, we now add those filters programatically.
This also ensures that the filters are the same between development,
production and testing environment.
|
|
|
|
|
|
|
