I struggled with this in my ODBC library as I wanted to encode exactly what the ODBC API returned, so setting the fields manually made sense.
Part of the reasoning for this was that time zones are handled by the DB, and may also be manipulated by SQL as well. I didn't want to introduce another layer of translation on top of this. Using initDateTime() means I assume a local time zone, but maybe it's not a local time zone in the DB data so doing this is supplying false information to the user. One option was forcing times to UTC, but maybe the SQL is actually [asking for a different time zone](https://docs.microsoft.com/en-us/sql/t-sql/queries/at-time-zone-transact-sql?redirectedfrom=MSDN&view=sql-server-ver15). However `times` currently only supports local and UTC so this starts to get very messy. In the end, I used `TimeInterval`, which I'm not really happy with to be honest. Probably I should just introduce a custom type as @GULPF mentions. Times are one of those seemingly simple yet horrendously complex corner-case situations.
