Client Settings - Service blocking Time Zone fails

[thewonderer73]

Prerequisites

• [X] I have checked the Wiki and Discussions and found no answer

• [X] I have searched other issues and found no duplicates

• [X] I want to report a bug and not ask a question or ask for help

• [X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARMv7

Installation

Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)

Setup

On a router, DHCP is handled by the router

AdGuard Home version

v0.107.43

Action

Adguard Home, Settings, Client Settings, Add Client (or Edit existing client). Add IP address of device. Device has MAC address set to static IP address in GL-iNET MT6000 (Flint2).

Select 'Block Specific Service' and choose just YouTube. Go to 'Pause service blocking' and select a time and time zone . Click save and error appears.

Delete Client and try again. Still same error message.

Expected result

Pause service blocking saves selected days and time successfully for Oceania / Brisbane. Blocked YouTube service is unblocked during the time specified.

Actual result

Error: control/clients/update | failed to process request body: unknown time zone Australia/Brisbane | 4000

Additional information and/or screenshots

No response

[ainar-g]

We cannot reproduce this, unfortunately.

failed to process request body: unknown time zone Australia/Brisbane

This likely means that your machine doesn't have that time zone installed. Please update the router's tzdata package, if you can.

I've also noticed that the list doesn't include a list of fixed timezones, which could help work around these issues, and we do need to add them. I've filed #6568 for that.

[jdawgzim]

I had same issue and this is how I fixed it:

1) ssh-ed to my Raspberry Pi and checked date with "date" command 2) It showed the wrong time zone 3) used "sudo raspi-config" to localize the time zone to where I live 4) Select Finish (had to hit TAB key to be able to select Finish) 5) "sudo reboot"

It's weird how inside AdGuard all showed the correct timestamps for events but it seems for this feature it goes to the OS for the time.

[thewonderer73]

Thanks. I just SSH into my gl-inet Flint2 and checked the 'date' It's set correctly... Sat Dec 30 10:22:50 AEST 2023

[odcold]

@ainar-g i'm having the same issue on router setup (entware) tried previous versions and the last one where timezone select works - 108.48 enabling verbose logs gives nothing, only error 400 maybe i can provide any additional info?

[ainar-g]

@odcold, see the messages above. First and foremost, update your tzdata, if you're able to. If not, you're probably stuck using Etc/ zones.

If you want to investigate further, the verbose logs are the way. I'm not sure what you mean by “only error 400” though. You should be able to see records with [debug] prefix in your service logs.

[odcold]

@ainar-g

i meant that even with verbose logs enabled this is all i get, related to this error

2024/02/21 13:05:50.433076 13628#2581 [error] POST domain.name:444 /control/clients/update: failed to process request body: unknown time zone Europe/Moscow
2024/02/21 13:05:18.304375 13628#2388 [debug] started POST domain.name:444 /control/clients/update
2024/02/21 13:05:18.308440 13628#2388 [error] POST domain.name:444 /control/clients/update: failed to process request body: unknown time zone Etc/GMT-3
2024/02/21 13:05:18.310054 13628#2388 [debug] finished POST domain.name:444 /control/clients/update in 5.36395ms

tried previous versions and the last one where timezone select works - 108.48

it's not, error doesnt show up but timezone is still in UTC

reason for this behavior is that by default paths to timezone are:

"/usr/share/zoneinfo/", "/usr/share/lib/zoneinfo/", "/usr/lib/locale/TZ/",

but in Entware its "/opt/share/zoneinfo/"

and also for localtime /opt/etc/localtime

https://github.com/Entware/Entware/blob/master/tools/go-src/patches/010-entware.patch

maybe there is a way to implement exceptions for these installations?

[ainar-g]

I feel like at this point it's easier to just not rely on the operating system's own tzdata at all. Go allows shipping a recent version of tzdata with the binary, and we'll probably go this way. I'll file a separate issue about that.