Timezones

[mathemancer]

Since we want to support storing times, dates, and datetimes, we need to think about time zones (TZs). We had a long and fairly meandering discussion on the Mathesar matrix channel, and ended up at the following:

Goal

We want to store datetimes in such a way that

1. The local time where the datetime was stored can be recovered.
   This would be useful for storing data where the local time is more relevant than a time comparable across TZs. For example, suppose I'm a biologist who's making a DB of what time of day birds sing most, and I travel the world collecting this data. In that case, I need to keep the ability to determine when birds sing from the perspective of the local time where the singing occurred.
2. Datetimes from different TZs can be compared and synced.
   This would be useful if I'm creating a DB of a bunch of remote employees' working hours in order to schedule Jitsi meetings. I need to be able to sync up a meeting between an employee in the UK with one in the US.
3. Datetimes can be displayed in the TZ of the reader.
   If we have (2) we can always recover this.

In order to recover the time from the perspective of where the time was stored, we need to store time zone info for that perspective. It seems like we came down to: "Store the datetime with the TZ". From this we can recover (1), (2), and (3) with some calculation. We could probably store the actual time as UTC, along with a TZ.

[kgodey]

This is a good summary of our discussion.

We'll need to be able to work with existing Postgres databases as well, which might not have TZ info. We'll need to disable features in the UI/API accordingly.

[kgodey]

@mathemancer I noticed you had omitted datetimes in #127. While I think this implementation should be our eventual plan, let's just start by using Postgres' datetime, which coerces to UTC.