Yep, a time field. Our not so unusual use case: agendas for an event. 12:30-1:00 pm talk, 1:00 pm lunch. That sorta thing, having a value with a throw-away date part feels messy.
I was just about to request this
I’m still really in need of this for events.
I understand there’s a difference between a full DateTime field (absolute time, backed by UTC and can be converted to anything) and a time-only field (relative time, relative to some other context such as an event date or local time). I’m guessing the fact that a time-only field would be relative and not locked to UTC is a reason why it’s not implemented as it’s not clear what the right design would be and people would certainly have conflicting needs.
I’ve thought about this for some time and my suggestion is a new time-only field which is absolute, by way of being backed by another reference date or datetime field. You would set the reference date field in the
validations tab the same way reference fields are set for slugs. For example:
event: date: Date schedule: - title: "..." time: Time # Base date backed by event.date field
You could even use the same widget layout as currently used for datetime but with the date part greyed out to make it clear that part is locked to the same value as another field.
This would also be handy for an event with a start time and an end time (eg. a music rehearsal is one I’ve tried to do before). Either the ‘end time’ would have its date part locked to the ‘start time’ date, or it wouldn’t be locked but its default value for the date part would snap to the start time’s date part (eg. if a band rehearsal would start at 9pm one day and finish at 1am the next day).
Finally, a use case I have at present is a multi-day event (ie. it has a start date and a different end date) with ‘schedule’ items throughout the event (say linked items or modular content). In this case an ideal setup would be able to not lock the date part of the ‘schedule’ items, but validate them as being within the start date end date interval.
I think the design you already have in Dato with the ‘validations’ section and the idea of reference fields would allow you to vastly improve the date handling and allow lots of use cases that other CMSs can’t do in a pretty clean way.