Closed nickdos closed 7 years ago
@nickdos Can you please confirm the timezone and get a copy of the image? thanks!
Sent email requesting image. I think it might be a camera trap image, e.g.
User was in Victoria when uploading the sighting. Photo is attached here.
Hopefully GH doesn't strip any data from image. If so, here is original: https://www.dropbox.com/s/wpqn0rmgzzkc920/Wallabia%20bicolor%202017%2004%2023.jpg?dl=0
Looking at the EXIF data, this image has a date/time of Date Time Digitized: 23 Apr 2017, 3:49:47 PM
(note this is PM) and for the GPS data it shows Date Stamp: 23 Apr 2017
& Time Stamp: 05:49:48 UTC
. These match the +10 difference for Victoria to UTC, as we'd expect.
When I upload it to the sighting page by dropping the image onto the image area, the date changes to 24-04-2017
& 01:49 AM
. Which is another 10 hours ahead of AEST or 20 hours ahead of UTC time.
Biocollect server's timezone is not configured properly. It looks like changing it might fix this problem. But need to do some investigation on how this will impact other Biocollect functionality.
@nickdos I have the timezone on the server to AEST. This should fix the problem for this user. But the bigger issue of dealing with date taken on different timezones from AEST remains. I think it needs wider discussion with developers and other stakeholders.
I went through this issue with the old pigeonhole and I think @chrisala has tried to deal with it in MERIT as well. From memory the best guess was to use JS on the client to get current timezone and then pass this through with the photo upload. You could also use the photo GPS data to work out the timezone.
I guess it is possible that the timezone the photo was taken in is different from the timezone from which the user uploads the photo. Deriving the timezone from GPS coordinate looks like a good option.
You'll need fallback if the photo has date/time but no GPS data - most decent SLR cameras provide timestamp but do not have a GPS in them.
ALA user sightings issue reported by user:
User later suggested the added 10 hours is in the wrong direction for the usual UTC issue, so this suggests the time is being corrected twice for UTC possibly?