Bug 12514 - location update returns "Could not download a new database" on some systems
Summary: location update returns "Could not download a new database" on some systems
Alias: None
Product: Location Database
Classification: Unclassified
Component: libloc (show other bugs)
Version: unspecified
Hardware: unspecified Unspecified
: Will affect most users Major Usability
Assignee: Michael Tremer
QA Contact: Peter Müller
Depends on:
Reported: 2020-10-28 16:15 UTC by Peter Müller
Modified: 2020-12-22 10:22 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2020-10-28 16:15:24 UTC
Triggered by https://community.ipfire.org/t/location-database-does-not-update/3613.

This seems to affect several people, but at the time of writing, I am unable to reproduce this myself.
Comment 1 Michael Tremer 2020-10-28 16:16:30 UTC
LOL what am I supposed to do with this?
Comment 2 Peter Müller 2020-10-28 17:07:45 UTC
The downloader fails (on some systems only?!) to verify the database as it expects it's timestamp to be older than the timestamp published via DNS.

However, as of today, both timestamps are equal to each other:

user@machine:~$ dig +short txt _v1._db.location.ipfire.org
"Wed, 28 Oct 2020 04:27:12 GMT"

[root@maverick ~]# python3
Python 3.8.1 (default, Feb  4 2020, 07:35:44) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import location
>>> d = location.Database("/var/lib/location/database.db")
>>> d.created_at
>>> from datetime import datetime
>>> datetime.utcfromtimestamp(d.created_at)
datetime.datetime(2020, 10, 28, 4, 27, 12)

As far as I understand https://git.ipfire.org/?p=location/libloc.git;a=blob;f=src/python/downloader.py;h=87bbb685043677f6a4a21689abd3c34aa3ce6295;hb=HEAD#l198, this is considered invalid.
Comment 3 Michael Tremer 2020-10-29 10:45:49 UTC
What timezone are those systems in? I am very sure that we are treating all timestamps in UTC and so the check should normally work.
Comment 4 paul 2020-10-29 11:48:23 UTC
My system is in MST (Mountain Standard Time), Arizona, US

[root@ipfire ~]# date
Thu Oct 29 04:38:57 AM MST 2020
Comment 5 Charles Brown 2020-10-29 22:03:56 UTC
Mine is US / Central CDT

[root@ipfire ~]# date; date -u
Thu Oct 29 05:03:24 PM CDT 2020
Thu Oct 29 10:03:24 PM UTC 2020
[root@ipfire ~]#
Comment 6 Charles Brown 2020-10-29 22:15:54 UTC
From my simple test, the db.created_at value is 5 hours less than the timestamp.  That would tend to indicate that db.created_at is in my CDT local time.
-- but like Jon, I'm no expert :-)
Comment 7 paul 2020-10-30 13:56:16 UTC
I installed (again) a fresh core 151. This time, as timezone I selected Europe/Athens instead of the usual America/Phoenix. Guess what, location update worked, I got a database 30 OCT 2020 04:27:17 GMT
Comment 8 Charles Brown 2020-10-30 14:14:54 UTC
Ditto Paul's experience: switched my tz to CET and the location update executed successfully; switched back to US CDT and got the failure indication
Comment 9 Peter Müller 2020-10-30 14:40:20 UTC
This is a bug in handling time zones < UTC indeed. :-/

Meanwhile, a fix made it into the libloc repository and will be released with Core Update 153:


Thanks for your patience and testing effort.