Date isn't displayed correctly on web view

Dreytac commented 4 months ago

First Check

[X] This is not a feature request
[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the documentation, with the integrated search.
[X] I already read the docs and didn't find an answer.

Homebox Version

v0.12.1

What is the issue you are experiencing?

I haven't used Homebox since September 2023 when this issue was still there. There is a complete thread on the issue at the old tracker:

https://github.com/hay-kot/homebox/issues/236

Seems it was never fixed as I'm still having the issue with a brand new install of v0.12.1. The bug seems to boil down to the front-end Javascript not converting the date/time correctly from the API when in certain timezones. In my case it's displayed as the day BEFORE the day the API returns. This causes an issue when you then save the item as it saves it using the displayed date/time.

How can the maintainer reproduce the issue?

Be in AEST timezone.
Create new instance of Homebox v0.12.1.
Create a new item with a purchase date (for example: 07/13/2024).
Observe the date is displayed as the day prior (eg: 2024-07-12).
Edit item and observe date is incorrect (eg: 07/12/2024).

Deployment

Unraid

Deployment Details

No response

SuperOlle commented 3 months ago

Can confirm that it's the same on my instance! I always have to pick the day AFTER the day I'm ACTUALLY wanting to put as date of purchase 😂

This ALSO causes the date to move backwards EVERYTIME you change something and then save it!

Docker on Ubuntu server VM.

katosdev commented 3 months ago

I'm struggling to replicate this and am thinking it might be related to locale... Will continue digging 😄

Dreytac commented 3 months ago

I think we came to the conclusion before that when submitting dates, it was submitting the date in whatever locale the app defaults to but then, when displaying that date back, it's converting it to the users locale, causing it to change. I think the problem was capturing the users locale when submitting the date was an issue.

I believe the date being shown in the API should be in the app default locale? Whereas when I submit a date and check the API, it returns it as the date I submitted (ie. in my locale).

OmegaDeathBunny commented 2 months ago

This is annoying so I would be willing to sponsor fixing this bug.

saschabrockel commented 2 months ago

I have the same now before it worked. Probably really an issue with the local time we are in. When I edit after midnight it works but if I edit during the day it's the behavior you all described.

katosdev commented 2 months ago

This is annoying so I would be willing to sponsor fixing this bug.

Thanks for the kind offer - If sponsoring, you can use the /boss command.

I'll be picking this one back up to try and do some more digging :)

vjaguilar commented 1 month ago

I just started playing around with HomeBox and hit this same issue. I've been looking into it and I think the root cause is a combination of using datetime for dates in the DB, and an incorrect management of timezones.

Checking the items table schema it looks like all dates are in datetime format and default to UTC. They're stored like this:

sqlite> select purchase_time from items; 0001-10-09 00:00:00 +0000 UTC 2023-04-20 00:00:00 +0000 UTC 2023-04-20 00:00:00 +0000 UTC 2023-06-07 00:00:00 +0000 UTC

That's what I have in the DB, but if we take the last date for example, I set that in the UI as 2023-06-08. Somehow the system substracted one day from the date I defined.

I'm running HomeBox as a docker container. I'm based in Spain and I've tried setting the env TZ=Europe/Madrid and TIMEZONE=Europe/Madrid to no avail, in both cases if I exec into the container and check the date, it's UTC. And UTC is what I get in the DB too. But from by browsers' perspective, this is what's PUT when I click save (excerpt from the full JSON doc using the web developer tools):

"purchaseTime": "2023-06-07T22:00:00.000Z",

So when I define the date to 2023-06-08, the client (either the browser itself or some JS code) transforms it to UTC (2023-06-08 00:00:00 GMT+2 = 2023-06-07T22:00:00.000Z), then the server-side code incorrectly trucates the time part to 00:00:00 leaving just 2023-06-07 00:00:00 UTC when inserting it into the DB.

Now, I have no experience with Go and just a little bit with sqlite, but things I'd check:

The alpine container is not honoring the TZ variable and it's defaulting to UTC. Digging around, looks like it needs to have the tzdata package installed to properly manage timezones. With a bit of luck, that'd make the Go code use the proper timezone in the DB too.
Investigate why the time part of the datetime sent by the client is truncated when inserting into the DB.
Besides that, why using a full datetime for a date? Using just a date could fix this. But maybe that's a sqlite limitation, not sure TBH.

Hope that helps :-)

katosdev commented 1 month ago

Impressive diagnosis, thanks @vjaguilar ! I’m hoping to look into this next week, will try and do some digging and see what’s going on here!

songlim327 commented 1 month ago

Hi @katosdev ,

seems like the issue is caused by JSON.stringify. I had submitted a PR to fix the issue, would you take a look and check if anything else need to be amended?

katosdev commented 1 month ago

Hi @katosdev ,

seems like the issue is caused by JSON.stringify. I had submitted a PR to fix the issue, would you take a look and check if anything else need to be amended?

Thanks so much! I’ll review this ASAP! :)

tankerkiller125 commented 2 weeks ago

This should have been closed with the merge of of the PR.

sysadminsmedia / homebox