My previous attempt (in f99ac7c) still had two clear problems.
Using the current offset from UTC for the local timezone
isn't really good enough: for timezones that have daylight
savings, for instance, it'll be wrong for events that happened
in the other state (so, events that happened during daylight
savings when the query is run outside of daylight savings,
for instance).

Also, the heatmap could still be wrong, because while we now
always had the right target date in mind, we were not smart
enough about making sure we fed cal-heatmap a timestamp that
definitely fell on that date in the local timezone.

This should fix both problems. Unfortunately, we need a new JS
library to do it. Getting the actual timezone (as opposed to
the offset) is a bit tricky; it is possible to get it from many
newer browsers via the Internationalization API, but some still
do not support this, so best practice is to use a library which
takes that value if possible, but otherwise tries to figure out
the timezone by requesting the offset at various points in time
and inferring from the reported values.

We change PagureLog.date_offset() from the previous attempt to
PagureLog.date_tz(), expecting a timezone name (Olson format),
and use it much as before. To solve the heatmap issue, we try
to get 12:00 on the target date in the local timezone, and
convert that to a timestamp.

Signed-off-by: Adam Williamson awilliam@redhat.com