All events at oSC23 are shown two hours later than they actually are in schedule.xml

[asdil12]

I'm submitting a ..

• Bug Report
• Feature Request

Current behavior:
The schedule.xml for oSC23 contains wrong timestamps.
(backup schedule.xml.txt).
The timestamps should be an ISO timestamps:

<event guid="sqG-rfXdWiK3WlowIYdSEg" id="4091">
  <date>2023-05-26T11:30:00+02:00</date>
  <start>09:30</start>
  <duration>00:45</duration>

The <start> tag contains the correct local start time but the <date> tag seems to be actually used for displaying the schedule
eg. in the giggity app. The <date> tag should be an ISO timestamp that should be localtime and contain the timezone (here +02:00).

Here you can see that for some reason the <date> contains an incorrect time that is 2 hours later than the actual <start> time (which is correct). So <date> actually contains a timestamp that is UTC+4 but claims to be UTC+2.

For reference here is a correct XML file from another event:
https://cloud.bib.uni-mannheim.de/s/3NdTDTKfDmz9pqy/download/bibliocon23.xml

[AndrewKvalheim]

Did this work correctly in the past?

I briefly looked into this and I suspect the underlying cause is that schedule times are stored in the incorrect time zone. The schedule editor sends times with no time zone and the controller receiving them doesn’t set any time zone.

#3090 recently compensated for this in JSON responses and it looks like a similar compensation has been attempted in the XML response—

osem/app/views/schedules/show.xml.haml

Line 19 in bd93753

%date= event.time.in_time_zone(@conference.timezone).iso8601

—but in_time_zone doesn’t actually change the time, only the displayed time zone. If I change the value of the time instead—

--- a/app/views/schedules/show.xml.haml
+++ b/app/views/schedules/show.xml.haml
@@ -19 +19 @@
-                %date= event.time.in_time_zone(@conference.timezone).iso8601
+                %date= event.time.change(zone: @conference.timezone).iso8601

—I get XML responses that look correct to me.