Improve time & timezone support

Conferences across the world have switched from physical conferences to virtual conferences. As we saw with DEF CON 28, this poses a logistical nightmare with regard to timezones.

DCIB mostly stuck to using PDT for time references, but there were numerous times when that caused confusion
attendees didn't adjust the offset correctly for their local time
DCIB used the wrong timezone abbreviation but did use the time value for PDT in at least one case
most villages used PDT, a few of those stated PST but were actually using PDT
a couple of villages used EDT
one village used UTC initially but then moved to PDT
staff members looked at official schedules and forgot that the time zone would vary
info.defcon had options for (local time, PDT, UTC) whereas the HT apps had options for local time and UTC, but not PDT
village/area/etc opening times varied (sometimes significantly), and because that info wasn't in info.defcon or HT, it was potentially ambiguous (or outright unavailable)
there was no way to tell what the "natural" timezone of any given event or village was. for example, if an event was being conducted in Singapore, localization would be fine, but it would be nice for DCIB to be able to internally see the staff local-time
on at least two occasions, i entered times incorrectly in HackerTracker Event Manager (HTEM), and didn't realize it until the error had been published

There's lots of room for improvement.

This is how HackerTracker currently requires that time be entered on an event:

I propose that we change it such that the event has a natural timezone (defaulted to the conference-timezone), and then you can enter an unqualified timestamp in the begin field and either a period stamp or a timestamp in the second field. For example:

Start Date: 2020-08-09T16:00 End Date: 1h

The "End Date" field should be understood by HTEM to be a fully qualified timestamp, unqualified timestamp, or period stamp, because they each follow strict formatting and are dissimilar. HTEM could then (upon save) rewrite that knowledge to be something like:

Start Date: 2020-08-09T16:00 End Date: 2020-08-09T17:00 Duration (derived): 1h

And actually save that into the database using the fully qualified timestamps (thus UTC) for both start and end.

Additional potential improvements:

clients automatically localize everything to the user's timezone
clients permit users to select whatever timezone they want to localize to, or to use the default/natural timestamps for every event
clients optionally display the timezone near/with times
the info.defcon schedule-view was apparently confusing to many, many people. someone brought that up on a DCIB call, and several other people immediately piled on in agreement that the current design is confusing. we need to refine how this looks, and do some kind of user acceptance testing (perhaps with DCIB staff and then DCGs?)
clients should consider including duration until events start (i.e., "begins in about 2 hours")
clients should consider including duration of event (i.e., "45 minutes")
if Discord is used again, we should consider writing a bot that detects properly formatted times (i.e., "18:00 PDT") and automatically returns other popular values, i.e., "18:00 PDT is 20:00 CDT, 21:00 EDT, 01:00 UTC".
another bot we might write is, i.e., "It's 10 minutes until 16:00 PDT! Click here to view a list of events [in AppSec village] that begin at 16:00 PDT!"

An example of how info.defcon's schedule view looked, for a single event:

Note that the day is displayed twice there, because some events cross the day boundary, and that was the easiest solution at the time. How that works for events that do not cross the day boundary might be able to be simplified, display-wise.

aNullValue / ngccs

Improve time & timezone support #19