Timestamps use wrong time zone

[niknetniko]

For example, an event might have a time stamp like this:

zeus.ugent.be/content/events/19-20/durf-doen-codenight.md

Lines 4 to 5 in 176139d

	time: '27-02-2020 17:30'
	end: '27-02-2020 23:59'

This will be converted to a DateTime by this code:

zeus.ugent.be/lib/helpers/preprocess.rb

Lines 87 to 95 in 176139d

	def convert_event_time_to_timestamps
	@items.find_all('/events/*/*.md').each do |event|
	# HACK: Strings in a format like "2017-10-05T20:45:00+0200" automatically get converted to Time
	event[:time] = event[:time].to_s
	event[:time] = DateTime.parse(event[:time])
	event[:end] = event[:end].to_s if event[:end]
	event[:end] = DateTime.parse(event[:end]) if event[:end]
	end

This date will be in UTC, which is not correct: the time in the event in wall time, meaning Europe/Brussels. Unfortunately, DateTime does not seem to support timezone, only offsets. This is will not work, since we need daylight saving rules to properly convert wall time.

To fix this, we'll probably need to migrate to using the Time class, which does correct for daylight saving rules. (Although the Time class does not account for calendar conversions, I doubt this will be a problem in our case). We could also import some helpers from rails, but I'm not sure if that is necessary.

---

The alternative is to just ignore it, and correct it when interfacing with external systems (which is how I found this).

[ninewise]

Could also be fixed by just having all times in UTC.

[niknetniko]

Could also be fixed by just having all times in UTC.

True. It does put the burden on converting to UTC on the author of the events, but that's probably not that hard.

[JensTimmerman]

+1 for everything in UTC

[niknetniko]

On second thought; putting future events in UTC cannot work reliably. On one hand, it is not trivial to write: the authors need to take into account the daylight saving rules at the time of the planned event. However, this would not be a big problem, since writing doesn't happen a lot.

A bigger problem is reading the dates back. When displaying an event or exporting it to the calendar, we want to show it in wall time (e.g. the time on the clock on a wall where the event takes place). Saving the date in UTC does not give us enough information to do this. For example, with the upcoming potential changes to the daylight saving times, all future dates would be wrong. Imagine we plan an event in the summer that starts at 10:00 am. We think "right, DST is on, so converted to UTC we put 08:00 am in the event file". Later, Belgium cancels DST. Our site will now convert our saved time 08:00+00 to our time with the new rules; resulting in 09:00 am in our time zone, which is not what we intended.

A correcter solution would be to save the datetime in "wall time", along with the time zone (which can be ours by default, so you won't have to write it in 99,99999% of the cases).

A post that goes into much more detail about this is http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html

[ninewise]

This problem only occurs when you show the end user the local time and want it to move along with time rule changes. Even though UTC is the one true time, we probably want to be friendly and show times in local time.

If you do want to show times in local time, I agree it should be saved in (local time, time zone). Since this is a website and we can't ask confirmation on time rule changes, storing the UTC-offset at time of writing isn't useful.

[werthen]

In one of the latest commits, I added tzinfo as a dependency. Perhaps we could use this for all timestamps?