I have been looking into this issue with "EXIF dates", and I have come to some conclusions and a solution which should be satisfactory. First of all, I probably have to agree, images with exif dateTimeOriginal should probably just display the given date without any timezone-related offset. In most cases, the visitor will relate the photo to the time it was taken in the location it was taken. Timezone offset doesn't seem useful. Besides, since we don't even know the timezone of dateTimeOriginal, we can't really assume timezone offset anyway.
Challenges ...
But hold on, there are still some challenges. We still need to convert dateTimeOriginal into a real date object, so that it can be manipulated, converted, translated and used for sorting in Javascript. We need this for various reasons:
dateTimeOriginal displays in the format 2014:05:19 09:50:18 which is not as readable as a human-readable converted value like Thu, Feb 8, 2018 11:27 AM.- The above also should be translated and localized for the visitors specific browser language.
- We need to calculate the Unix time for each date, so that it can be used for sorting.
- Create various short format variations for the gallery layouts.
- Calculate the "timeago" human-readable format.
The problem of course when creating a real date object, is that a date-time is always timezone-specific. A time is either relative to UTC, browser or where the photo was taken. There is no such thing as a date-time relative to nothing. When we create a date object from exif dateTimeOriginal, we must therefore always assume a timezone.
Originally, date was relative to server. This is wrong of course, since the server could be in a different location than both the image and the visitor. Later on, we assigned the date relative to UTC(GMT), which at least provides some consistency and removed server-time from the equation. However, this could also be wrong, since EXIF date isn't necessarily in UTC, and then converting it to browser timezone (or not), will likely be wrong.
Solution
The final solution, is to assume the exif date itself is relative to the browser timezone. Technically, this is not entirely correct, since the photo might be taken in a completely different timezone of course. However, since exif date doesn't include timezone info, and since we don't want to add any offset anyway, we might as well assume the exif date is relative to the visitors time ... Result? It means exif date 2014:05:19 09:50:18 will display the same time, without offset, in human-readable format Thu, May 19, 2014 9:50 AM for all visitors across all timezones.
I'm pretty sure this is what everyone wants, right?
This fix will be included in the next release in a few weeks ...
