Make NFC software aware of time zones and DST about vesper

[HaroldMills]

Continuing to think about this issue, I currently think the following would be best:

• Store times in an archive as UTC.
• Include station timezone information in an archive. I'm not sure yet exactly what form this will take, but it might include a standard time UTC offset, an indication of whether or not DST is observed, and if so, the DST start and end times for each year for which there are data in the archive. This might be accomplished with two tables, a TimeZone table and a DST table. The TimeZone table might have columns for time zone name (e.g. US Eastern), UTC offset, and DST name (e.g. US). The DST table might have columns for DST name (e.g. US), year, start time, and end time.

Tools like the NFC Wrangler that add clips to an archive will need to be able to convert local times to UTC as needed. Tools like the NFC Viewer that present clips from an archive should allow the user to choose whether displayed times are UTC, local standard time, or local daylight time.

[HaroldMills]

In an NFC archive:

1. Each clip has a UTC start time.
2. Each clip is assigned to a night, which is the local start date of the night on which the clip was recorded.
3. Each station has an associated time zone. As far as I am aware, the Olsen time zone database includes all of the time zones that we might need.

In our implementation of this:

1. The start time of a clip will be represented in Python as an aware (i.e. with an appropriate UTC tzinfo) datetime object. Note that a datetime can easily be converted to a local time using the datetime.astimezone function. I believe we can use pytz time zones for all the stations of which I am aware.
2. As in the current implementation, the night of a clip will be represented in the database as a 7-digit integer of the form YYYYMMDD, but in Python code as a date object. We might consider changing the database implementation to a date, however, unless that's a lot slower. It's also not clear to me that we really need to store nights at all. Would it suffice to define a night as a certain UTC time interval (e.g. noon to noon local time) and use that interval for queries? We currently use nights to help accelerate queries that return clip counts, but I suspect that we may just want to store the clip counts directly (adding some redundancy to archives, but facilitating certain kinds of analyses), which might reduce the need for storing nights.
3. The time zone of a station will be represented in the database by its Olson name (e.g. "US/Eastern"), and in Python code as an appropriate timezone instance obtained from pytz. If it turns out that at some point we need time zones that are not in the Olson database, we can use non-Olson names for them and provide some fallback mechanism for obtaining whatever information is needed from the names.

[HaroldMills]

The archive now requires that clip times be specified (to the add_clip method) with the pytz.utc time zone, and also yields them (via the get_clips method) in that form. Each station has a time zone, stored persistently as an Olson time zone name. The viewer displays clip times in the local time zone.