camera photos have timestamp off by one hour from utc

Bug #1418639 reported by Kyle Nitzsche
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
The Savilerow project
Triaged
Undecided
Unassigned
mediascanner2
New
Undecided
Unassigned

Bug Description

I just wiped and reflashed the phone and took a photo.

 The mediascanner db has this entry: sqlite> select * from media;
 /home/phablet/Pictures/com.ubuntu.camera/image20150205_162408958.jpg|image/jpeg|1423153450:309584|image20150205 162408958|2015-02-05T17:24:10|||||0|0|0|2448|4352|0.0|0.0|0|3

Note the he timestamp : 2015-02-05T17:24:10

However, the phone's own idea of the time is an hour different:
 phablet@ubuntu-phablet:~$ date
 Thu Feb 5 16:26:18 UTC 2015

The phone's Time and Date settings show it is set to Etc/UTC timezone (UTC+0).

Actual UTC time is what the date command shows: 16:26

I expected the timestamp to be exactly UTC time.

This causes the My Photos scope to get the time wrong for the photo. The time is used to determine which category the photo is placed in, so in some cases it will be in the wrong category. The timestamp is also displayed to the user in the photo preview.

phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 227
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2015-02-05 05:08:11
version version: 227

Not sure if the issue derives from Camera or Mediascanner2.

Revision history for this message
Bill Filler (bfiller) wrote :

Photos taken with the camera-app use local time, not UTC, and store this in "Image timestamp" field of the exif meta-data. This is the same thing Android and iOS do in their camera apps.

Revision history for this message
James Henstridge (jamesh) wrote :

Bill is correct about photos dates being in local time. We do include a time zone off set in the database if it is encoded into the photo, but it looks like this isn't the case here.

And just for completeness, here's the details of my phone set to local time:

    phablet@ubuntu-phablet:~$ system-image-cli -i
    current build number: 188
    device name: mako
    channel: ubuntu-touch/ubuntu-rtm/devel-proposed
    alias: ubuntu-touch/ubuntu-rtm/14.09-proposed
    last update: 2015-02-06 10:00:54
    version version: 188
    version ubuntu: 20150205
    version device: 20150116
    version custom: mako-1.1

    phablet@ubuntu-phablet:~$ date
    Fri Feb 6 10:04:47 AWST 2015

And when I take a photo its metadata is scanned as:

    /home/phablet/Pictures/com.ubuntu.camera/image20150206_100514888.jpg|image/jpeg|1423188316:121812|image20150206 100514888|2015-02-06T10:05:16|||||0|0|0|1836|3264|0.0|0.0|0|3

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

So the issue seems to be that the image meta timestamp is in local time, but the meta data lacks a time zone offset, therefore the db is not able to deduce the actual time the photo was taken, which confuses the scope.

Here;s meta data from a camera pic I just took:

$ exiv2 print image20150206_075322374.jpg
File name : image20150206_075322374.jpg
File size : 1670721 Bytes
MIME type : image/jpeg
Image size : 2448 x 4352
Camera make : bq
Camera model : Aquaris E4.5
Image timestamp : 2015:02:06 07:53:25
Image number :
Exposure time : 1/100 s
Aperture : F2.4
Exposure bias : 0 EV
Flash : Fired
Flash bias :
Focal length : 3.5 mm
Subject distance:
ISO speed : 186
Exposure mode : Not defined
Metering mode : Center weighted average
Macro mode :
Image quality :
Exif Resolution : 2448 x 4352
White balance : Auto
Thumbnail : image/jpeg, 20352 Bytes
Copyright :
Exif comment :

Revision history for this message
James Henstridge (jamesh) wrote :

Right. If the file has EXIF tag 0x882a (TimeZoneOffset), the media scanner include that offset in the date field of the database. There is a description of the tag here:

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html

This tag doesn't seem to be covered by the standard though, which is probably why most cameras don't produce it:

http://www.exiv2.org/Exif2-2.PDF

Is there something in particular you want to use the time zone offset for?

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

The fundamental problem is that there is an off-by-one error in the hour of the timestamp in the db, as I initially stated.

For example, I just flashed with --wipe and have:
phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 230
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2015-02-09 10:56:42
version version: 230
version ubuntu: 20150209
version device: 20150129-c75dcfb
version custom: 20150129-528-26-182

After the welcome wizard, I took a picture.

The db now has this:
sqlite> select * from media;
/home/phablet/Pictures/com.ubuntu.camera/image20150209_110013113.jpg|image/jpeg|1423479614:443753|image20150209 110013113|2015-02-09T12:00:14|||||0|0|0|2448|4352|0.0|0.0|0|3
sqlite>

HOWEVER, the hour on the timestamp (2015-02-09T12:00:1) is WRONG by one hour.

Here is the system date/time:
phablet@ubuntu-phablet:~$ date
Mon Feb 9 11:04:12 UTC 2015

This problem means my My Photos scope is unable to determine the correct time for the picture and displays the wrong time to the user and in some cases may put it in the wrong date range category.

Note that the off-by-one-hour persists after I set the timezone to my correct local timezone in settings.

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

After setting my phone to EST (which is UTC-5):

The exiv data from the new photo has the correct local timestamp:

$ exiv2 print image20150209_110642361.jpg | grep times
Image timestamp : 2015:02:09 06:06:43

This is correct, here's system time:
Mon Feb 9 06:11:34 EST 2015 (although I ran this command a few minutes later)

Here's the new db entry:
/home/phablet/Pictures/com.ubuntu.camera/image20150209_110642361.jpg|image/jpeg|1423480003:503753|image20150209 110642361|2015-02-09T12:06:43|||||0|0|0|2448|4352|0.0|0.0|0|3

This db entry seems to be UTC time, but it seems wrong by one hour. (UTC time is 11:06 right now).

Revision history for this message
James Henstridge (jamesh) wrote :

Sorry for not getting back to you more promptly. I still haven't been able to reproduce what you're seeing (I don't have a krillin, but I wouldn't have expected any hardware dependence here).

In case it was time zone related, I switched to the same US time zone and took a photo. The exiv2 tool reports the date as "2015:02:17 06:37:28", and it is stored in the database as "2015-02-17T06:37:28".

Since I can't reproduce this, could you attach a sample image that exhibits this problem to the bug report?

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

Hi James.

So the problem continues - off by one hour. Attaching an image just taking by the camera for which the data is as follows:

==== Here's the exiv data from pic:
$ exiv2 print image20150218_201804172.jpg
File name : image20150218_201804172.jpg
File size : 1015233 Bytes
MIME type : image/jpeg
Image size : 2448 x 4352
Camera make : bq
Camera model : Aquaris E4.5
Image timestamp : 2015:02:18 20:18:05
Image number :
Exposure time : 1/17 s
Aperture : F2.4
Exposure bias : 0 EV
Flash : Fired
Flash bias :
Focal length : 3.5 mm
Subject distance:
ISO speed : 288
Exposure mode : Not defined
Metering mode : Center weighted average
Macro mode :
Image quality :
Exif Resolution : 2448 x 4352
White balance : Auto
Thumbnail : image/jpeg, 29824 Bytes
Copyright :
Exif comment :

==== Here's relevant bits from cli:

phablet@ubuntu-phablet:~$ date
Wed Feb 18 20:17:20 UTC 2015
phablet@ubuntu-phablet:~$ sqlite3 .cache/mediascanner-2.0/mediastore.db
SQLite version 3.8.7.4 2014-12-09 01:34:36
Enter ".help" for usage hints.
sqlite> select * from media;
(HERE IS WHERE I TOOK THE PIC)
sqlite> select * from media;
/home/phablet/Pictures/com.ubuntu.camera/image20150218_201804172.jpg|image/jpeg|1424290685:483714|image20150218 201804172|2015-02-18T21:18:05|||||0|0|0|2448|4352|0.0|0.0|0|3
sqlite>

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

system for the above ^ comment:
phablet@ubuntu-phablet:~/Pictures/com.ubuntu.camera$ system-image-cli -i
current build number: 113
device name: krillin
channel: ubuntu-touch/vivid-proposed
last update: 2015-02-17 16:36:26
version version: 113
version ubuntu: 20150217
version device: 20150210-95b6a9f
version custom: 2015021

NOTE: I did set it to writable

Revision history for this message
Alan Pater (alan-pater) wrote :

Hi all. I stumbled on this issue looking for info on setting timezone info in exif. I'm a contributor to the exiv2 library and have been hacking away at DateTime conversions.

The sample file metadata does indeed show 2 different times, none with any timezone information.

$ exiv2 -pa image20150218_201804172.jpg | grep DateTime

 Exif.Photo.DateTimeOriginal Ascii 20 2015:02:18 20:18:05
 Exif.Photo.DateTimeDigitized Ascii 20 2015:02:18 20:18:05
 Exif.Image.DateTime Ascii 20 2015:02:18 21:18:05

That last field, Exif.Image.DateTime, is the image modified time according to MWG guidelines (1). Without knowing anything about mediascanner, I would suggest that Exif.Photo.DateTimeOriginal might be what you want to be storing in the db.

(1)http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=37

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

Per my test on the following image, the time it show on the "My Photo" Scope is correct now, and the time is in locale time zone instead of UTC (per #1)

I'll mark this invalid in savilerow.

phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 3
device name: arale
channel: ubuntu-touch/stable/meizu.en
last update: 2015-08-03 11:16:26
version version: 3
version ubuntu: 20150720
version device: 20150709-8965e37
version custom: 20150716-819-8-42

Changed in savilerow:
status: New → Invalid
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

this could only happens to krillin but not on arale. also check bug LP: #1468585

Changed in savilerow:
status: Invalid → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.