https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37902
--- Comment #39 from David Cook <[email protected]> --- (In reply to Jonathan Druart from comment #30) > David, if you are asking what's the next step then have a look at bug 37952. No, that's not what I meant, but you can ignore my earlier question, as I've done more digging and I think I understand better today than yesterday. If I understand correctly, Koha::DateTime::Format::RFC3339->parse_datetime() should correctly parse both 2024-09-26T18:41:24.268Z and 2024-09-26T14:45:36-04:00 and set the time_zone appropriately. I looked back through your patches and Koha::Object->attributes_from_api() pre-patch, so I better understand what bug you're trying to fix here. I haven't thoroughly reviewed and understood every line of code, but I get the general idea. -- I was wondering if there would be any negative unintended consequences of fixing this bug... but we should be OK anywhere that dayjs() with the RFC3339 output or Date().toISOString() is used. If no timezone is provided, it's just assumed that the server timezone is used, right? -- The % for the -like operator is still going to be a problem, but... I think that's a future problem, which will be part of bug 37952 anyway, as you say Jonathan, so I'll comment more there... -- 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/
