Use of UTC time stamp instead of local time


#1

Not sure if this is mobile apps specific as it could be a generic issue, but why does the Mapillary app (and I guess, the entire service as a whole) insists on recording the images using UTC timestamp and not the actual local time where the images were captured?

It’s so annoying when opening the app and looking at the Uploads page and seeing the date/time of sequences showing as ‘2:18 am’ or Tomorrow AT 4:51 AM’ which just don’t make sense?


#2

We need to store them in UTC because of technical reasons, but the time should be displayed in your local timezone of course. I’ll file as a bug but will need to know if it’s iOS or Android.


#3

Thanks @Anders. I’m using iOS app version 4.8.20.

Please see attached screenshot from the app. As you can see, I recorded the sequences in a country which is UTC+6:30 and so one sequence is showing as being recorded at 2 AM, which is clearly not correct.

You mentioned that the time should be displayed in local timezone. Can you clarify what you mean by that?
In my case, I went to south-east Asia and recorded a series of sequences. My phone’s clock is set to local-time (and assuming this bug doesn’t exist), the recorded sequences will be shown in local time.
Due to not having WIFI in that country, I did not bother uploading the images, until I return to UK.
Once I’m in UK, the phone then switches back to GMT. If I then open the app again and look at the sequences recorded when I was in SE Asia, the timestamps will be shown in what, the local time where they were recorded or GMT time where I am currently?


#4

Thanks!

Hmm good question. What makes the most sense to me at least is to display it as the same time as when it was captured, i.e. if I captured some images at 10 o clock in the morning in Asia somewhere it should always show it like that even when I get home to the EU.

It can become a problem with relative dates and travelling between timezones though so should perhaps not use them.


#5

Oops! Forgot to attach the image.


#6

Yes, my preference is for the app to show the local times of the images when they were recorded, regardless of where you are physically.

However, I do have another question. When I transfer the images to laptop for processing in Lightroom prior to uploading them, the filenames themselves are in UTC. Do you intend to keep them that way?

I don’t mind so much if the image files themselves are in UTC, but if the folder names are in local time, then that would help greatly to know when the images were captured.

Having said that, if the app allows me to rename the sequence folder names (there’s a separate request for it) or alternately, to add a description to the folder name then it will help a great deal with organising the sequences when I’m on trips and need to capture many sequences.


#7

UTC is always better. But I agree the GUI should apply the TZoffset. It could even infer that from the GPS information.

Of course, the edge case will be if you did a capture which involved crossing a time zone boundary… what to display then?


#8

Timezones are more complex than you imply. Python tools have trouble with them. Usually the time zone is not recorded. If you record the offset it still doesn’t define the zone properly. What about daylight saving? Then you would be out by a zone. If the zone is recorded then you need a database for daylight saving which changes over the years. We have recently extended ‘summer’ hours. I have yet to see a jpeg with any of this time metadata, I assume they are always local time - or whatever the silly user set the camera to. I went on holiday and left my camera set on my home time.


#9

I very much agree with you.


#10

Why not just make another folder with your trip name and place the datestamped folder name under that? I am doing this for each day’s capture because each subfolder appears to be a sequence.
Note that there are still problems with timezone based datetimes. You have to allow for daylight saving as well. The filenames just have the offset to utc added as a +/-hours:minutes. That does not define the timezone clearly because it might be an adjacent zone. Unfortunately you have to calculate allow for the time of year for a given zone that goes back many years because daylight saving times have changed often. the pytz python module allows for this with a normalize() function. Even the EXIF timestamps do not store a zone name! Zone names have a code and a full name. So I am in NZDT or NZST which are codes for ‘Pacific/Auckland’ in the timezone database.
I have noticed my photos are taken “in the middle of the night” recently too. It must be a bug in the website, not your zone travelling.