[DTOSS-9752] add starts_at to ClinicSlot

[cameronhargreaves1-nhs]

Description

Because clinic and clinic slot start times are both datetime, it is currently possible to have a clinic slot that starts on a different day to the clinic, which means having a date on the clinic slot start time is redundant.

This PR starts the transition from clinic slot time being a datetime field to a TimeField, for a future PR to remove the datetime field altogether.

Jira link

https://nhsd-jira.digital.nhs.uk/browse/DTOSS-9752

Review notes

Review checklist

• Check database queries are correctly scoped to current_provider

[gpeng]

We should probably make this nullable in this first migration so as we don't get the default value set. It probably doesn't matter as we don't have any existing data, well, we do but it's demo data and we're going to repopulate it anyway but good practice to get into I think. Make it nullable -> populate them all -> make it un-nullable in the subsequent PR when we get rid of starts_at.

[gpeng]

Just had a thought about this... If we only store Time is it going to make handling displaying the local time correctly a pain? We'd still need the date from the Clinic to localise the time from UTC wouldn't we? @MatMoore any thoughts? Maybe just adding validation would be a simpler approach after all.

[MatMoore]

Just had a thought about this... If we only store Time is it going to make handling displaying the local time correctly a pain? We'd still need the date from the Clinic to localise the time from UTC wouldn't we? @MatMoore any thoughts? Maybe just adding validation would be a simpler approach after all.

Hmmm I think there are complications here for sure.

• Only datetime objects have an associated timezone, and I don't think TimeField does any timezone conversions automatically. If we decide to store a UTC time in the TimeField, then yeah, we'd need to fetch the date from the Clinic record in order to present it properly (taking into account daylight savings). I don't think that's a good idea.
• We could store the local time in the TimeField, but that means not using UTC consistently in the DB, and it will be more fiddly to convert to an unambiguous datetime later on.

So yeah I think you're probably right that the validation method makes more sense.