Time Zone issues after updating to v0.16.x

[Starfiresg1]

Describe the bug After updating I noticed a timezone discrepency in new speedtests. It seams the "created at" column and the json-data of the test now contain both UTC time. Prior to the upgrade the "created at" column contained local time. I use a MariaDB-Database which has the local timezone set:

SELECT @@global.time_zone, @@session.time_zone;

@@global.time_zone @@session.time_zone
SYSTEM SYSTEM

output of date command on command line: Wed Feb 21 22:18:04 CET 2024

CET (UTC+1) is used

I've had the following settings that worked prior to upgrading to the new release:

In the results table new entries have UTC-time in both the JSON-field and "created_at" column. Older tests before the migration had the local time in the created_at column and display with the correct local time in the result list and the charts.

The public dashboard is even stranger - it backdates the result one hour from UTC - displaying the result at UTC-1.

To Reproduce Steps to reproduce the behavior:

1. Run a manual speedtest at an specific local time
2. Click on 'Results' or refresh the dashboard
3. Time of the result in list and graph is not displayed in local time

Expected behavior Time in the result list and the graph should be in local time as they did in v15 I think.

Environment (please complete the following information):

• OS: debian (docker)
• Architecture: amd64
• Browser: Firefox
• Version v0.16.6 (Linuxserver,io)
• Linuxserver.io MariaDB-Docker running 10.11.6 of MariaDB

Screenshots Test run at 21:47 local time Admin Dashboard displays 20:47 as last entry Result list displays 20:47 as test time Public dashboard displays 19:47 as last entry

Logs Nothing oblivious in the logs

[hoorna]

I am seeing exactly the same behavior (also using version v0.16.6 from Linuxserver) both on the Speedtest tracker webpages and in the database. My MariaDB and the Speedtest containers are both set to the local timezone (with environment variable TZ). If you switch "Database has timezone" off then the times presented on the Result page are OK for new tests (of course not for old ones).

[OddSquirrel]

On my end, I can't even choose time zones or servers anymore. Both show arrows, but nothing happens when I click on them:

Are you guys running v0.16.6 as well?

[hoorna]

@OddSquirrel, as I wrote earlier: yes I am also running v0.16.6 (from linuxserver)..

I have created the Speedtest-tracker container with a docker-compose file and with the TZ environment variable set. For the database I am running MariaDB (version 11.3.2) in a docker container which is also created with a docker-compose file and with the TZ environment variable set. I switched off the "Database has time zone".

Since one of the v16 versions (I really do not know which one) all times are correct now (on the Dashboard page as well as on the Result and Public pages). In new database records, all times are now written everywhere in UTC (in the "data" field and in the "created_at" and the "updated_at" fields).

@alexjustesen, it appears that the solution to the previously reported Timezone issues with the "Database has time zone" switch is no longer necessary. Edit and in addition: also @alexjustesen: I believe the change of the times in the database to UTC occurred after I started using the Linux server image. The Linux server image may handle time zones in a different way.

[OddSquirrel]

@hoorna Sorry, must have missed the version part. I'm running PostgreSQL on my end.

@alexjustesen Do you have an eye on that issue with the non-choosable time zone and server, or should I raise a dedicated ticket for it?

[alexjustesen]

@alexjustesen Do you have an eye on that issue with the non-choosable time zone and server, or should I raise a dedicated ticket for it?

Can you open a separate issue and also add your browser info?

[OddSquirrel]

Can you open a separate issue and also add your browser info?

Tried again with Vivaldi, just to make sure. Didn't work. Tried Firefox, didn't work, either. Updated Firefox, suddenly it worked. Tried Vivaldi again, now it worked in there as well.

I either have some poltergeist roaming my IT or I need to change up meds. Please excuse me while I show myself the door. 🙈

[alexjustesen]

@Starfiresg1 can you share your docker-compose.yml config?

[Starfiresg1]

version: '3.3'
services:
    speedtest-tracker:
        container_name: speedtest-tracker
        ports:
            - '<redacted>:8765:80'
        environment:
            - PUID=1000
            - PGID=1000
            - DB_CONNECTION=mysql
            - DB_HOST=mariadb
            - DB_PORT=3306
            - DB_DATABASE=<redacted>
            - DB_USERNAME=<redacted>
            - DB_PASSWORD=<redacted>
        - APP_KEY=base64:<redacted>
        volumes:
            - /opt/docker/speedtest-tracker:/config
            - /opt/docker/speedtest-tracker/web:/etc/ssl/web
        image: 'lscr.io/linuxserver/speedtest-tracker:latest'
        restart: unless-stopped
networks:
  swagnet:
    external: true
  mariadb:
    external: true

Database is defined external (Linuxserver.io MariaBD) - used by multiple docker-containers in case it is needed, here it's it compose:

version: "2.1"
services:
  mariadb:
    image: ghcr.io/linuxserver/mariadb
    container_name: mariadb
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=<redacted>
      - TZ=Europe/Berlin
    volumes:
      - /opt/docker/mariadb:/config
    ports:
      - <redacted>:3306:3306
    restart: unless-stopped
networks:
  mariadb:
    external: true

Network mariadb is a user defined bridget network which allows docker containers needing access to the mariadb-docker talking to each other and the mariadb-container.

[alexdelprete]

Timezone issues will always be present, unless proper management of the connection to the db is implemented. Assuming that a db MUST be in UTC is a totally wrong approach, and all the issues are a consequence of bad assumptions.

This has been discussed tens of times in the past, last conclusive discussion and diagnosis of the problem is here, you can read the entire thread if you're curious about details.

I guess the nail can be removed from the coffin (ref. last post of that old thread) because it was not a proper solution but an ugly workaround. So here we are...always discussing about the same old issues and having different timestamps in the UI, the DB, etc.

Here's an example of the timezone chaos, last test made at 00:25:

Public dash (2hr error):

Admin page (1h error):