Closed EcoGabe closed 2 years ago
Hi @EcoGabe,
Thank you for your contribution. I will take a closer look later and test it. Honestly, at first sight, it looks a bit messy 🙈.
Which typo3 version (10 or 11) did you use?
Version 10
Hi @EcoGabe. I am currently hesitating to merge this change because the actual bug originates from the TYPO3 core. Since this is only a "visual bug", it is not so important to fix.
You can find the bug report here: https://forge.typo3.org/issues/96890 When I have some time, I may try (contribution to the core is sometimes hard) to fix it there.
Thanks for finding that in Core, I'll try to take a look at it myself.
Hey @EcoGabe , Hey @okmiim
I will close this issue. If we fix this in EXT:calendarize this "logic" should move to a Utility/Service like this class: https://github.com/lochmueller/calendarize/blob/master/Classes/Utility/DateTimeUtility.php But I also think we should push this & fix this in core.
Regards, Tim
Currently, for US time zones (or anywhere with a negative UTC offset; west of Greenwich and east of the IDL), there is a discrepancy between the date shown in the title of the record, and the actual
start_date
value. Despite being a date-only value, it gets appended a time string and converted from UTC (e.g. for Los Angeles,2022-02-10
gets turned into2022-02-09T16:00:00-08:00
). This results in the event being labelled one day in the past.This change converts
start_date
values with a time string back to UTC, with a correct date.