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.
But hold on, there are still some challenges. We still need to convert
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.
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 ...