Wrong timezone information in schedule.xml export

[a-tze]

The element of the elements in the export have an trailing Z indicating UTC while the datetime itself seems to be a local time.

[differentreality]

I think that's happening because the time during scheduling is saved in UTC instead of conference timezone, and that's what we should really address.

[sharawatankit]

@differentreality hi, I am beginner want to work on this, can I? if yes then please direct me from where to start.

[Ana06]

@differentreality

I think that's happening because the time during scheduling is saved in UTC instead of conference timezone, and that's what we should really address.

Not really, it is not needed to save the schedules in the conference timezone. If we do so we have to deal with that in all the schedule and that's a lot of changes and we will also complicate the code. I think it is enough to take this into account when exporting schedule.xml

[Ana06]

@aki94 take a look at https://github.com/openSUSE/osem/blob/master/app/views/schedules/show.xml.haml :wink:

[nikhilgupta1211]

@Ana06 can i work on this ?

[differentreality]

@nikhilgupta1211 what exactly are you going to work on - what are you going to implement in order to solve this?

[nikhilgupta1211]

@differentreality i think as @Ana06 said it is not needed to save the schedules in the conference timezone so for this issue we just have to convert the time zone in show.xml.haml to conference time zone which we can do with the help of in_time_zone

[differentreality]

This is a delicate point, what we save in the DB is indeed UTC, but when we schedule something at 9am, this is supposed to be 9am of the conference time.

[a-tze]

If I might comment here... I have no idea how your records are stored in database, but seeing you talk about "conversion" of time gives me the feeling that you're doing it wrong. Please, do not convert datetimes. The database does that for you. If it doesn't, you're doing it wrong. The timezone that ends up in the XML actually doesn't matter. It just has to be correct, which is the actual issue here (trailing Z but not UTC). So if you have UTC in your database (and know for sure that it is UTC) then please export just that with the trailing Z and everything is fine regarding the schedule export.

[Ana06]

@differentreality it is much easier to work on UTC for the schedule, we just have to take care of rendering it properly in the places where we want to include the timezone.

[differentreality]

@Ana06 I did not say otherwise. I am just saying that if the event is scheduled at 9am, the DB records 9am UTC, but what the organizer really means when the event was dropped in the schedule is 9am of local time of wherever the conference is happening, hence when we display the time in schedule.xml we should not convert that time, just not present as UTC.

[Ana06]

@differentreality ok :+1: I understood you wrong :wink:

[nikhilgupta1211]

@differentreality so a simple fix would be to remove the trailing Z in the xml .

[differentreality]

And how will we know in which timezone those times in the xml are?

[nikhilgupta1211]

@differentreality We can add a timezone tag in xml to show the conference timezone or we can do

tm = event.time
offset = tm.in_time_zone(@conference_time).utc_offset()
tm = tm.in_time_zone(@conference.timezone)
tm += -offset

This will convert the timezone to conference timezone without changing the time. for Eg : Sun, 05 Mar 2017 11:00:00 UTC +00:00 to Sun, 05 Mar 2017 11:00:00 IST +05:30

[Ana06]

@nikhilgupta1211

This will convert the timezone to conference timezone without changing the time.

then just render the timezone of the conference withouf dealing with time changes and offsets. :wink:

[a-tze]

Ok then. And what happens if your conference is today and tomorrow and takes place in Europe?

[Ana06]

@a-tze

Ok then. And what happens if your conference is today and tomorrow and takes place in Europe?

What do you exactly mean?

[a-tze]

I was referring to the this-year-magic-weekend with DST change. Is the conference timezone +0100 or +0200 then? Does it work if you plan the conference in February and schedule something for March 26th 10am, is it then magically 11am after DST change (it shouldn't be) and so on. In my experience you get around those problems only if you save every timestamp with timezone. (And yes, we did already have a conference over DST change with frab and it did work surprisingly well ;) )