Calender Picekr chooses one day before

[el3ctrician]

Any calendar picker will choose one day before the clicked day. The bevaiour is consistent in all calender date pickers.

I can work on a fix as soon as i have time

[el3ctrician]

i did some digging and it seems that dayjs uses local time while i don't understand the logic in the code wether we use local time ot UTC time ? specifically here it assumes that what was selected is UTC while in fact it is local time. So to clarify when does UTC is used and when local time is ? what is the best approach to fix it ?

[faburem]

Internally UTC should be used everywhere. Only for display purposes dayjs should convert to the local time zone.

[el3ctrician]

so the issue is the follwing the tinydatepicker returns the date in locale not in UTC and hence when you select the date it assumes local (in my case CET +2 ) and selectes midnight for that. When you then use dayjs to convert to UTC it then substracts two effecitvely selecting the previous day at hour 22. so if you store in UTC you will store the wrong day because the selected date is set to midnight ... we can fix it by fixing the visualization to convert it back to locale before showing it but that means that for all positive timezones you will always write the wrong date in DB ...

[faburem]

thanks for the analysis. Can we then just convert the date returned by tinydatepicker to correct UTC to fix this issue or am I oversimplifying the issue?

[el3ctrician]

that's exactaly the bug: the code converts the tinydatepicker to UTC ! for a fix we have two routes:

1. before dispalying when you fetch back the date to apply it to the selected date you convert it back to locale as tinydatepicker expects. This can potentially create another issue where two users on two different timezone will see different dates since tinydatepicker uses locale midnight of the selected day.

2. ditch the UTC all together and store the date as a simple date string based on the user selected (DD-MM-YY) and store it that way in the DB. That would enforce same dispaly among all users and i think is more correct but it is a conceptual change

let me know what do you think

[faburem]

Good thoughts. I think we can go with option 2 but we need a compatibility layer for the existing dates stored in the database (should not be too hard). Also we have a setting to track the start time, but we can easily store this in a dedicated field in the database. I think in the long-term this change makes a lot of sense but it will need some considerations to get it right. Happy to collaborate on a PR, I will unfortunately only have time to start working on this in 1-2 weeks from now.