Wallos seemingly not applying TZ
Hi all, my runtipi tubs in a Ubuntu VM on my proxmox controller. As far as I can tell time/date/timezone are all set correctly and working at proxmox, VM and runtipi level.
I have other apps, like n8n, that timezone matters and it is working correctly.
I am setting up wallos and noticed my notifications were not coming through, reached out to wallos support and after updating the app notifications and now sending but they appear to be a day behind.
I'm in Australia Melbourne and TZ set to Sydney (since Melbourne is usually not accepted) and I had 2ctest subscriptions one for 13th and one for 14th. I set the 13th to notify on due date and 14tg not notify one day before. So at 9am on the 13th (yesterday) I should have got both notifications.. instead I got a notification for a test subscription I had made set to the 12th with on due date notifications.
If I look at the audit log for wallos in the runtipi interface it looks to be logging audit events with my correct date time.
App support has suggested I override the TZ reference to the env file which I will try today.. but I'm not confident it will help.
Any ideas?
12 Replies
i just checked. the wallos app has the environment var set to the specs of wallos.
please post the output of
./runtipi-cli debugi just checked my installation and the configured timezone from tipi is used in the container as it should be.
yes my timezone setting shows correctly in runtipi UI as well and it works fine for other apps. but it is not working with wallos. subscriptions due on the 13th with a reminder set to trigger on the due date are not sending till 9am on the 14th
hmm. i would blame wallos in that regard.
there is a similar issue https://github.com/ellite/Wallos/issues/291 that never really got a solution.
GitHub
Inaccurate payment time · Issue #291 · ellite/Wallos
My time zone is Asia/Shanghai. I set the payment date for a certain subscription to April 28th, but now it's already the 29th, and the next payment date will still be displayed as April 28th. B...
Yea that's what I figured.. but I'm not confident enough in my knowledge to trust that I was correct that everything date and timezone wise was correct at my end.
I guess it's time to look for a different solution to my needs or start digging into the apps code to see if I can find the bug.
Thanks for your help
one thing to test would be to use another timezone for testing. maybe its something with yours and the way wallos uses / sources it. i mean there would be a lot issues on github if this would not work generally i guess
maybe, although i am wondering if maybe its an issue with the offset, aus sydney/melb is +11.
the only reason i mention that is in the logs it shows the time stamp as my actual correct date time stamp for my timezone but then still also has +11 on the end. usually when displaying a timestamp it would show gmt 0 date time +11 or jsut show the converted date time.. not convert the date time and show +11 still (see screeshot).. so maybe its using my correct base timezone but then trying to add 11 hours to it meaning that when the cron job runs at 9am my time and compares maybe its throwing out the results?
idk im grasping at straws as this has thrown me a bit lol
hmm this is interesting. when i restart the app and it runs its checks for sub dates to updte etc the datetime stamp there is differet:
Ibdug around a bit more and fur some tests changing timezone etc.
Issue appears to be that when comparing the subscription payment date and the current date it's not factoring in the timezone and since my timezone is +11 when it runs at 9sm on the 15th by time it will still be the 14th without the plus 11.. so a dub set to 15th doesn't notify (for sane day notifications), it would notify me on my 16th 9am.
Anyone with an offset of +9 or below wouldn't have the issue assuming I'm correct anyway. And would have to have an offset of more that -15 to have the issue the other way around.
I hope I'm right anyway because this is doing my head in lol
Looks like it's worthy a wallos issue
Yea I spun up a seperate VM replicated the issue with just docker compose, no runtipi. So I will close this off and just keep working with wallos dev on the issue. Thanks for your help