I accept that storing in UTC is best. However, just as you convert from the local time to UTC, do the same to display in local time.
If the issue is what time it was when that event happened. For e.g. birth may have happened at 7am in Chicago and display is currently in Los Angeles (where it would 5am), one could display 5am. Displaying 12noon (which is UTC) is worse, IMO.
If the person entering the data has entered the correct date/time, then displaying a local version of it is preferable to displaying an unfamiliar UTC version.
> For e.g. birth may have happened at 7am in Chicago
There are two types of date-time.
Firstly, events such as birth and death. GEDCOM does not actually support this. Times should be added as notes.
However, many applications allow you to store a time, and webtrees will happily display times.
Clearly, these are all local time, and should not be converted.
Indeed, webtrees treats these just as any other custom/non-standard field, and just displays them as-is.
Secondly, the last-edit timestamp. GEDCOM does not allow (or even specify) a timezone.
Since we may have editors working on the same tree at the same time, but in different
timezones, our only option is to store these timestamps in a fixed time-zone.
As explained in the GITHUB issue, converting these to local time is difficult, because the
date and time are treated as two separate, independent fields. (A consequence of the design
which was based on the first type, above). We can't convert time without also converting the
date - and the code to display the time doesn't have easy access to the date.
In short, it's not a "quick and easy fix". This is why the github issue is still open.
Note, that the timestamps shown in the control panel (not genealogy data) are stored as
a system timestamp. These can (and are) converted to local time.
It's just the genealogy data that causes problems.
Ok, good - yes, not converting date/times for birth/death events and displaying them as is, is the best.
WRT last modified/edit times, I beg to differ. If you are able to change it to UTC, then the same class of functions should be able to change it back to local. It doesn't matter if there are multiple editors working in different timezones. What they see is a UTC date/time converted into their timezone, which should be consistent.
I haven't implied that it is quick/easy. Let me just add my support to the enhancement request of showing these times in localtime instead of UTC.