steph072 When looking at the fireworks in Sidney at New Year'Eve...it's midnight on location of the firework and all viewers worldwide look at this event in future. Or is it important to know that a midnight firework happens at 1pm in Europe as an example? Depending on the location on Earth one will never see a midnight firework but a middle of the day firework?
But this is an example from your specific scenario.
Let's say USER is in Germany, SERVER is in US. User uploads a file at 14.00 local time, and after upload, it says the file was created at 09.00 (server time) ... Doesn't seem weird to you? In most cases, the user doesn't know and doesn't care where the server is located, so why should it say some entirely different time for the file? In this case, it makes sense to use the users timezone offset ... If the file was uploaded at 14.00 user time, it should display 14.00. Does that seem like a strange concept?
Now let's complicate this even further. Let's pretend the above is used to share files for a group of users across different locations. If we don't offset timezones, how is user A supposed to know when user B uploaded a file? User A might see the file was created 5 hours ago or in 5 hours, even if the file was uploaded 1 minuted ago. Surely you see a scenario where displaying dates relative to timezones is useful.
I can definitely agree in your case with "photos" that just printing out the dateTimeTaken stamp is mostly agreeable. However, then I need to make a shift to separate the logic between EXIF dateTimeTaken and photos/files without this EXIF value stored ... Basically, if dateTimeTaken don't do timezone offset, else do timezone offset.
There are more challenges, because it's not only about displaying the time stamp no matter what it says and even if it's malformed. For SORT feature to work properly, I need to convert the date to a pure number Epoch Unix Timestamp, and this value is always relative to GMT. To do this conversion, I kinda need to know the absolute time of the photo. If I pass the dateTimeTaken to unix time stamp without any further information, it will calculate the timestamp as if the photo was taken in the same timezone of the server.
It's all actually more complicated than I first anticipated, with reference to why I made the initial fix in the first place. This means we need to differentiate between files with date from EXIF, and files with date from the server file system. This itself is not entirely logical of course, because we don't really know the actual true EPOCH time of images with EXIF if we can't assume the time is GMT.
It's definitely not as easy as you think.
