#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 , 6 years ago
| Attachment: | img013255.jpg added |
|---|
comment:1 by , 6 years ago
| Cc: | added |
|---|---|
| Keywords: | exif added |
comment:2 by , 6 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 , 6 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 , 6 years ago
| Milestone: | → 20.01 |
|---|
comment:6 by , 6 years ago
| Keywords: | timezone added |
|---|



I don't remember how we globally display times for image mapping. Do we always display UTC times?