#18015 closed defect (fixed)
JOSM displays unexpected EXIF time, maybe due to wrongly considering the user's timezone
Reported by: | skorbut | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 20.01 |
Component: | Core image mapping | Version: | |
Keywords: | template_report exif timezone | Cc: | StephaneP |
Description
What steps will reproduce the problem?
- Open the attached image
- Look at the JOSM window titled "Geotagged Images"
- Look at the upper left corner, at the line starting with "EXIF time"
What is the expected result?
The line should read 2019-07-19 13:14:08.985
, which is also the value that exiftool
prints for the "Date/Time Original" EXIF field.
What happens instead?
The line reads 2019-07-19 15:14:08.985
instead, i.e. it differs 2 hours from the value stored in the EXIF field.
My hypothesis is that JOSM adds two hours (=my offset to UTC timezone) to the "Date/Time Original" EXIF value. (Small note: I manually edited the "Date/Time Original" EXIF value to be sure which exact value is read. Other candidates would have been "GPS Date/Time", "Create Date", "Modify Date").
Please provide any additional information below. Attach a screenshot if possible.
URL:https://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2019-08-05 20:49:54 +0200 (Mon, 05 Aug 2019) Build-Date:2019-08-06 01:30:53 Revision:15283 Relative:URL: ^/trunk Identification: JOSM/1.5 (15283 en) Linux Ubuntu 16.04.6 LTS Memory Usage: 1495 MB / 3641 MB (292 MB allocated, but free) Java version: 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10, Private Build, OpenJDK 64-Bit Server VM Screen: :0.0 2560x1440 Maximum Screen Size: 2560x1440 fonts-noto: fonts-noto:all-20160116-1 Dataset consistency test: No problems found Plugins: + apache-commons (34908) + editgpx (34908) + photo_geotagging (34908) + photoadjust (34977) Last errors/warnings: - W: No configuration settings found. Using hardcoded default values for all pools. - E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first - E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first - W: Region [geoimage-thumbnails_BLOCK_v2] Resetting cache - W: Region [WMTS_BLOCK_v2] Resetting cache
Attachments (1)
Change History (7)
by , 5 years ago
Attachment: | img013255.jpg added |
---|
comment:1 by , 5 years ago
Cc: | added |
---|---|
Keywords: | exif added |
comment:2 by , 5 years ago
I've already see some strange behavior with the image's timestamp when I use my scripts and Josm, but I had never investigate.
I just tested on Windows and Ubuntu. Josm seems to add the timezone offset to the exif timestamp.
As Exif metadata usually doesn't store any timezone data, I don't see any real value to add the local time offset.
comment:3 by , 5 years ago
In my opinion, since the field is titled EXIF time
, there shouldn't be any conversion applied to its value.
Alternatively, there could be an additional field called EXIF time (converted to UTC)
(or similar).
comment:5 by , 5 years ago
Milestone: | → 20.01 |
---|
comment:6 by , 5 years ago
Keywords: | timezone added |
---|
I don't remember how we globally display times for image mapping. Do we always display UTC times?