Sundays always display zero hours worked

[rctaylor157]

I've noticed this on the Dashboard screen under Statistics. Here is an example:

The hours are logged properly, and show up in Reports. I haven't filed a bug here before so let me know if there's any additional information you need!

[te-online]

Hey @rctaylor157 Thanks for reporting! This looks like an annoying issue 😬

I've just tested on my own installation, because I had a suspicion it could be "fixed" by changing to a Locale that starts the week on Monday, but for me it's the same (expected) result. Maybe you have more luck (or possibly need your week to start on Sunday)?

Having basically ruled out this possibility, I'd think that it's related to the somewhat broken timezone support (#120), which I will look into soon 🙏

[rctaylor157]

I've noticed it again, this time on the Reports! The first day is blank, even though it's not a Sunday. I tried it on a month that began on a Saturday and it was the same thing, blank. It seems to be tied to the first day displayed, regardless of what day of the week that is, so it might not be linked to timezones.

[te-online]

Thanks for following up!

I believe the issue is that the "start" date the frontend requests data for is calculated in the wrong way. It may therefore very well be related to timezones or locale settings. It could also be that the frontend asks for the right data, but the backend somehow converts the date and returns data for the wrong timeframe.

When I was talking about the Sunday/Monday thing, I was more referring to the fact that you can set your week to start on Monday or set your week to start on Sunday. So it wouldn't be about which day the month starts on, but your Nextcloud/browser/system setting in regards to when your week begins.

But since I couldn't reproduce that by changing my settings I assume that the "start of the week" setting is not a factor here.

If you have the chance, could you take note of the URL in your browser when you load a report on the reports page where entries are missing? I'm especially interested in the "start" query parameter the page asks for.

[Gene-W]

Hello,
I'm not sure if you'd rather have this in another report or if it's best to reply here with the same issue. I am also not seeing Sunday in Reports and I work every Sunday. My location is set to begin week on Sunday . If it helps, here's the URL from the Reports page in my Nextcloud:

/apps/timemanager/reports?clients=9820862b-0335-4a7b-bb11-284ce0b90db0&projects=4b62bfb7-7a87-45c8-a6fa-47a529c2e5dd,d89b459b-19f7-4e6a-a1f5-8559b3272e7c&tasks=4388404c-6dba-4bdc-ac76-d55dffc80f40,bd337acd-e3b4-4011-8726-6f3999a43fc8&status=

[te-online]

Thanks for the details, I’ll try to reproduce this soon. Can you provide some details about the database and system time zone you’re using?

[Gene-W]

Can you provide some details about the database and system time zone you’re using?

Thanks for your work on this app and for your help. My timezone is CST (Chicago) US. My database shows mysql version 10.5, are there any other details about the database I can provide?

[agoeckner]

I'm also in Chicago timezone and my hours are shifted by one day. For example, Sunday is blank (I did not work on Sunday), Monday is blank (even though I did work), Tuesday displays the Monday hours, and Wednesday displays the Tuesday hours.

Both the report and the dashboard are wrong.

However, the list of time entries shows them on the correct days.

EDIT: Adjusting times to be before 7PM results in display on the correct day, as described in #120.

[te-online]

@agoeckner Interesting 🤔 Are you recording time entries using Nextcloud in the browser or the Android app?

[agoeckner]

I'm using both. The entries seem to be recorded correctly because they show up properly in the entries list. It seems to just be a display issue in the Dashboard/Report pages.

[te-online]

I believe all lists are using some JavaScript to display the date and time in your local timezone, whereas here it's queries to the database (as in dashboard and reports) seem to deliver the wrong results to you, not including the records they should.

Can you tell me the last part of the url when you're setting a filter for the past week on a report?

It looks like this for me: /reports?start=2024-06-24&end=2024-06-30&clients=&projects=&tasks=&status=

[agoeckner]

This is what it looks like for me.

This week: /reports?start=2024-06-30&end=2024-07-06&clients=&projects=&tasks=&status=.

Last week: /reports?start=2024-06-23&end=2024-06-29&clients=&projects=&tasks=&status=

[te-online]

Thanks for providing that, I will look into it as soon as I can 🙂

For reproduction of the issue, is there a chance you can also share your server's timezone (date or date +"%Z %z") and your timezone locale as set in Nextcloud (https://nextcloud.example.org/settings/user)? 🙏

[agoeckner]

Thanks, Thomas.

Here is the output of date: Mon Jul 8 11:14:49 CDT 2024
And of date +"%Z %z": CDT -0500
And the locale: English (United States)

[te-online]

Just a little update: I'm prioritising this issue currently, because it seems quite annoying for some people (and I'm getting more and more curious why it's so difficult to get to the bottom of this). I will return with an update next week.

In the meantime, any information on your timezone settings, things you've been observing etc. can be helpful, so please everyone just add them here 😊

[agoeckner]

I appreciate that, thank you! All of my observations are listed here already but please let me know if you need me to collect specific information.

[te-online]

Thanks! I believe I have found the source of the issue.

When timezones cause DateTimes to shift to another day, they are resolved to the incorrect day.

Example: When the UTC date is 2024-07-15T00:29:00+00:00, the timezone-corrected date may be 2024-07-14T19:29:00, for example. So that puts the entry into the wrong "bin" when generating the graphs.

Additionally, there are some dates in the code that are given without a time. This means their comparison to other dates in the respective SQL queries is all wrong, because timezones don't even play a role there and matching in done only based on a 10-letter formatted date.

All in all, quite a few places to clean up. I'm in the process of doing that now.

Not sure why I missed those problems before. My best guess is because everything works fine with my dinky little timezone offset over here, so I didn't bother investigating thoroughly enough.

[te-online]

@rctaylor157 and @agoeckner – can you check if your timezone is now better supported in v0.3.15? I believe that I fixed most issues, but it'll be interesting to see if it actually fixes your issues 😊

[agoeckner]

Awesome, thank you so much @te-online! I just did a quick test and it looks good so far. I'll report back as I continue to use it throughout next week.