Date and time - time zone

[oomtoo]

Entries after 7:00 p.m. are recorded the following day. Could it be because of my time zone setting (UTC-5) even though NextCloud has this setting correct? Thank you so much.

[te-online]

Hey @oomtoo, thanks for reporting! 🙂

Yes, it could very well be because of the timezone. Generally, entries are saved in the database in UTC. When you use the filter, the browser is being asked to convert your local date to UTC and uses that to filter entries from the database. Maybe some of that logic is flawed.

I'll try to reproduce this issue soon and if I can, I will try and include a fix in the next version 🙏

[31SFX4]

I noticed some problems around timezones too. Caveat: I haven't had time to test this in detail and I not very experienced with SQL, so perhaps I'm wrong, but it looks to me that timemanager is not actually storing the time correctly at least when the server timezone is not UTC.

My server timezone is set to Germany (CEST, currently 2 hours ahead of UTC) (I know this is not ideal but I can't change this). Now I added an entry in timemanager just now (at 19:14) and with the mysql statement

select start from oc_timemanager_time;

I actually get 2023-04-16 17:14:00. However my understanding is that the statement returns datetimes in the server timezone (although they are internally stored as UTC), so given that the server is at CEST it should also show 19:14 instead of 17:14, or am I misunderstanding something?

When I add an entry with the Android App, then the datetime in the database matches what I expect, but the timemanager web form shows it 2 hours in the future.

[devattendant]

@31SFX4 17:14:00 is right for your SQL statement. I can't check the code right now and my time is limited at the moment sitting in the Australian nowhere with a broken laptop being repaired, so I can't check what part of my timezone implementation pull request was used in the repo.

Long story short the code never checks the server timezone used but simply assumes it is UTC, so it will always subtract (in your case) the 2 hours before storing the entry. Which makes sense, as when you would move your datebase to another server in another timezone, you would need to recalculate everything.

Not sure what the app does though.

[te-online]

I second @devattendant's opinion:

• I'd expect SQL to return the date in UTC, which is does
• I have a suspicion the Android app fails to convert dates from the phone's local timezone to UTC before sending them to the server, which explains the difference for those entries

Next I will look at the filters and observe if they create the correct range when running the SQL queries to show time entries.

Did you see other places in the Nextcloud app where times are not converted correctly (when they haven't been created by the Android app)?

[oomtoo]

I hope this information contributes...

In my case, in NextCloud, the hours are recorded on the server without the UTC setting.

In the FontEnd, in queries to edit the records, the UTC setting is applied correctly.

But in the CSV export and the graphical reports (Statistics.svelte) is where the UTC adjustment fails.

Thank´s!

[te-online]

I think I can somewhat reproduce your issue when exporting reports. Sadly, I lack the time right now to investigate further and provide a fix. Allow me a few weeks and I will include a fix in the next release 🙂

[31SFX4]

@te-online Thanks for the explanation. After some testing and reading I also came to the conclusion that the Android app handles this incorrectly. So you can ignore my comments as they have nothing to do with the original issue.

[alexanderdd]

I face the following issue, is it related?

1. Track time from 16:00-17:00 on android app
2. open this tracked period on web interface, the time there is 18:00-19:00

My phone and my Nextcloud personal settings are CEST, so UTC+2
and you say that the database always records time in UTC
so maybe this is the reason why the time in webinterface is shown two hours later?

[devattendant]

@alexanderdd I guess so. I was not following the app development at all, but if it was not updated during the last year, it does not support timezones yet, therefore you will have UTC times in the app and local times in the web.

[alexanderdd]

related issue in the android app https://gitlab.com/joleaf/nc-timemanager-mobile-app/-/issues/12
there is already a pull request, hopefully it gets merged soon 🥇

[te-online]

@oomtoo Can you check again with v0.3.15 just released if reports show the right entries now? 😊