Relative Times

[lostcarpark]

A number of things (session times, availability times mostly) are stored as time fields, and are relative to the start time of the convention.

On the surface this seems very clever.

Until the programme team tell you that they are having a quiz night on Thursday night, and they need you to move the start of the convention for programme forward a day. Then you discover all the programme items have moved forward a day, so you do a bulk update and add 24 hours to them. Then you discover participant availability is out of step, so you need to add 24 hours to those tables.

So I can't help wondering would it make more sense to store session start times as an actual datetime field, and store the full date and time of each item.

[bcholmes]

I hear you. One of the things that's a little bit attractive about the current set-up is that one could, for example, make a relatively last-minute change to push the con back by a week, and you could accomplish pretty much just by updating the start date. (I initially didn't like the way times were represented, but eventually came around).

That's a case that's probably extremely rare, mind you, so maybe that's not good justification to keeping things the way they are.

[LVerhulst4321]

Oh wow. I never thought about the havoc that would occur by changing the start date of the convention while scheduling is being done. Ouch!
But on the other hand, if you need to change your con weekend, and sessions are scheduled to specific dates, then all of those dates would need to be changed instead of them automatically following the start date of the con. That's not pretty either.
I will have to think this over a bit to try to figure out which way would cause less hassle.

On a separate note, if changing the start date of the con is added to a config table and added as an option for an admin, then checking can be put into place to notify said admin of issues.

[lostcarpark]

I think the reality is that if you had to move to the con to a different weekend, the availability of participants would also change so you would end up with with a massive change to the schedule anyway.

And if the start field was a datetime, it would still be feasible to add 7 days to all programme items, the way I did.

I think I will be impressing on future programme teams that moving the start date is a pain in the a**, so if there's a possibility of an "evening before" event, to set the start date a day early from the outset.

Agree we could have have warnings for admins who try to move the start date. It would also be possible to code a "move convention date" function that would fix up all the date fields accordingly. However, I think the number of times it would be used would be low, and the number of edge cases would be high, so it would probably not be worth the effort.

[lostcarpark]

I was discussing outputting Planorama data to ConClár with Henry, and he mentioned that Planorama stores all dates in UTC, and converts to local time at output. I think this is something we should consider for the future. I'm not sure how well our current approach handles conventions over a DST changeover weekend. I'll be discussing with Henry whether the ConClár extract will convert the dates to local time, or whether to add a config flag to ConClár to tell it the file contains UTC dates.