https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36217
--- Comment #26 from Jonathan Druart <[email protected]> --- Please test the patch, it addresses the issues correctly (I think!) Did you look at js-date-format.inc? $datetime is dealing with the server's timezone. To test it: Set timezone to America/Argentina/Buenos_Aires, which is UTC-3 (in $KOHA_CONF) Client is CEST (UTC+2) I am doing my test now, it is 4:20 in Buenos Aires 7:20 UTC 9:20 CEST In the console: let now = new Date(); now Date Thu Sep 05 2024 09:20:38 GMT+0200 (Central European Summer Time) now.toISOString() "2024-09-05T07:20:38.077Z" $datetime(now.toISOString(), { dateformat: 'iso' }); "2024-09-05T04:20:38.3838-03:00" Which is what we want to send to the server. (In reply to David Cook from comment #24) > (In reply to Jonathan Druart from comment #19) > > This patch suggests to revert the previous attempt to fix this problem. > > The date was using the client-side's tz and so the "last hour" was not > > matching the one from the server. > > The problem isn't the client side TZ. The problem is the server side TZ. > > In ktd, the server side TZ is UTC, so the unpatched version works as > expected. > > However, in practice, many servers are set to TZs like Australia/Sydney or > America/Montreal. > > When that happens, the feature works very badly, because the wrong time is > used. I have been working on date handling in Koha for a while, no need to explain more the problem, I totally understood it. Hence the patch and my suggestion to revert what has been done :D -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
