[FEAT] Clarify timezone configuration (TZ vs APP_TIMEZONE vs DISPLAY_TIMEZONE) in README
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 1/5
- Geschätzter Aufwand
- Unter einer Stunde
- Anfängerfreundlichkeit
- 88/100
- Issue-Typ
- Dokumentation
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- docker, laravel
- Bereich
- documentation
Rechercherichtung
Beginne in readme-vars.yml mit der Überprüfung von opt_param_env_vars und app_setup_block. Aktualisiere die Beschreibungen der Zeitzonenvariablen und füge die Erklärung zu den drei Variablen hinzu. Überprüfe anschließend, dass die README-Dokumentation klar zwischen TZ, APP_TIMEZONE und DISPLAY_TIMEZONE unterscheidet und eine konsistente Einstellung empfiehlt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Is this a new feature request?
- I have searched the existing issues
Wanted change
Improve the README's documentation around timezone configuration. Speedtest-tracker reads three separate timezone environment variables, and the interaction between them isn't obvious from the current README:
TZ— container OS timezone (cron, system logs)APP_TIMEZONE— Laravel's internal timezone (config/app.php→env('APP_TIMEZONE', 'UTC'))DISPLAY_TIMEZONE— timezone shown in the web UI (config/app.php→env('DISPLAY_TIMEZONE', 'UTC'))
Currently:
APP_TIMEZONEisn't listed inreadme-vars.ymlat all.DISPLAY_TIMEZONEis listed as optional with the description "Timezone for the UI." and no guidance.
Users following the standard LSIO pattern of only setting TZ end up with a UI that displays UTC times regardless of their TZ value, which is a common source of confusion.
Reason for change
This trips up users (myself included) who reasonably expect TZ alone to control displayed times, as it does in most other LSIO images. A short note in Application Setup that all three should generally be set to the same value would save a lot of head-scratching and forum/Discord traffic.
Proposed code change
A small, documentation-only change to readme-vars.yml:
- Add
APP_TIMEZONEtoopt_param_env_vars. - Expand the
DISPLAY_TIMEZONEdescription to recommend matchingTZ. - Add a "Timezone configuration" subsection to
app_setup_blockexplaining the three variables and recommending they all be set to the same value.
--- a/readme-vars.yml
+++ b/readme-vars.yml
@@ -33,13 +33,24 @@ opt_param_env_vars:
- {env_var: "DB_DATABASE", env_value: "", desc: "Database name (postgres/mysql)."}
- {env_var: "DB_USERNAME", env_value: "", desc: "Database username (postgres/mysql)."}
- {env_var: "DB_PASSWORD", env_value: "", desc: "Database password (postgres/mysql)."}
- - {env_var: "DISPLAY_TIMEZONE", env_value: "Etc/UTC", desc: "Timezone for the UI."}
+ - {env_var: "APP_TIMEZONE", env_value: "Etc/UTC", desc: "Timezone Laravel uses internally for scheduling and stored timestamps. Recommended to match `TZ`."}
+ - {env_var: "DISPLAY_TIMEZONE", env_value: "Etc/UTC", desc: "Timezone shown in the web UI. Recommended to match `TZ` so displayed times line up with the container clock."}
- {env_var: "PRUNE_RESULTS_OLDER_THAN", env_value: "0", desc: "Days to keep test results."}
# application setup block
app_setup_block_enabled: true
app_setup_block: |
Access the web UI at `<your-ip>:80`, the default credentials are [email protected] / password
+ ### Timezone configuration
+
+ Speedtest-tracker reads three separate timezone variables and they each control a different layer:
+
+ * `TZ` sets the container OS timezone, used by cron and system logs.
+ * `APP_TIMEZONE` sets the timezone Laravel uses internally for scheduling and stored timestamps.
+ * `DISPLAY_TIMEZONE` sets the timezone shown in the web UI.
+
+ Setting only `TZ` (the common pattern with other LinuxServer.io images) will leave the application and UI on UTC. For consistent behaviour set all three to the same value, e.g. `Europe/London`.
+
For more information check out the [project documentation](https://docs.speedtest-tracker.dev/).
I have this change prepared locally on a branch. Happy to open a PR if you'd like — just wanted to check first since CONTRIBUTING.md asks for an issue rather than a PR for small doc fixes. Let me know which you'd prefer.
- Vorherrschende Sprache
- Dockerfile
- Sterne
- 186
- Forks
- 8
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus linuxserver/docker-speedtest-tracker
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 38/100
linuxserver/docker-speedtest-tracker#81 · 7 Kommentare ·
-
no-issue-activity
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
linuxserver/docker-speedtest-tracker#80 · 4 Kommentare ·
-
no-issue-activity
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
linuxserver/docker-speedtest-tracker#79 · 7 Kommentare ·
Alle Issues in linuxserver/docker-speedtest-tracker
Ähnliche Issues
-
sync-en
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
ACK_WAITING HELP_WANTED UPDATE_CS
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
OWASP/CheatSheetSeries#2458 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
l3montree-dev/devguard#3101 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 1 Tag
-
area/documentation status/need-triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 95/100
google-gemini/gemini-cli#29548 ·
Maintainer antworten meist innerhalb von 1 Tag