What do you do with your camera clock time in relation to time zones?

I hear you! What a pain. I thought about standardizing on GMT, but I name my photos by date, and since I'm not in Europe, that means many photos would be on the wrong day locally. So, I leave my cameras all in EST (even in the summer — one hour off is no big deal), and automatically batch-correct my phone pics so they're never in DST either. When travelling far, the dates get off — oh well.

So that's what I do. But in any case, like so many organizational things, the important thing is to be consistent. That way, you know where you are, and can even batch-change your scheme later.

My cameras (Nikon D300s and Canon S95) have the capacity to use time zones. For instance at the moment I'm in Brazil, and rather than change the time I've left them on GMT (or UTC if you're being modern about it) and changed the time zone to -3. In the last 4 months I've been through three time zones. Part of my work involves photography and having the right time stamp on the photos is an important part of my workflow, so having the capacity to change time zone is extremely useful.

I try to be careful and update the timzone setting in the camera to the local time zone. Note that this doesn't change the absolute time recorded in the metadata, but only the local time offset. Since I take a lot of outdoor shots, I leave the GPS receiver connected to the camera on by default. It will automatically set the camera clock when it receives a signal, so I never have to explicitly set the camera's clock. GPS is time you can trust because the system inherently works on time. It has to know time very accurately to compute position.

We recently changed to daylight savings time here, and I did remember to change the timzone in the camera. I would really like this to be automatic, working with the position data from the GPS. Would it really be that hard for the firmware to have a timzone map, then look at the absolute time and the position to determine the local time?

Maybe a timezone map is asking for too much data in a camera, and then you have to update the firmware as political changes are made to timezones. Still, this can't be that much data for moderm memories. My car GPS receiver has street level detail of large areas of land stored in it. The extra data for timezones must be small in comparison, yet it doesn't do that and I have to manually set the timezone on it too. I don't understand why they solved 99% of the problem and skipped the last relatively easy 1%.

Interesting question. Since my Canon 50D does not have a built in GPS, I use an Amod AGL3080 GPS Data Logger to track where I am when I'm shooting. I can then either use exiftools or Aperture to merge the GPS log with the photos.

The matching is done by the datetime stamp in the EXIF information.

I haven't played with it, but I bet its a lot easier if I keep the camera's time accurate within a small error window.

exiftools have switches to correct time zone, but I haven't played with Aperture in this scenario.

Despite living in the US, I set my camera clock to UTC. I didn't think of using EST, though since I'm a Westerner that doesn't appeal to me too much. :)

It is a little annoying that photos taken in the evening show up on the wrong day. However, I thought never needing to reset the time zone on the camera, and UTC being the easiest time "zone" to convert to any other time zone, outweighed this problem.

If you do photography both with a real camera, and with a smartphone, then you can't use the "keep everything in the home time zone approach".

Not if you use your phone as a watch, anyway!

I have this problem for a lot of the photos I've taken. Even worse, I'm using different cameras, some of which record GPS (including date and time) and some of which don't, thus leaving the GPS date/time fields empty.

I like to have my data tidy so I'm currently developing my own photo management tool for which I need to specify how time and date are kept.

I decided to leave all my cameras in UTC and in case of the phone, to set it to UTC afterwards. The reason for this is that it makes it much easier to sort the photos by date taken (according to EXIF GPS timestamp). I keep local time as date/time for each picture in the EXIF date/time fields and have UTC in the GPS date/time fields (and the system timestamp for created and - if applicable -modified. Also I add the non-standard timezone field which is strictly speaking not necessary as it can be calculated from the timestamp difference but it is a nice to have.

With regards to EXIF v2.31 (p49) time-zone integration (2016) and XMP time-zone guidelines (p34) it might make sense to look at this problem once more.

Local time is important especially in the human-based interaction with pictures. Looking at a sunset photo one expects the clock to show something in the second half of the day, for breakfast photos rather the opposite.

UTC time on the other hand is necessary for programmatic organization. Correlating pictures with a GPS track (check geosetter, looks outdated and dubious, but is up to date and best tool I could find for this purpose). To show pictures over a spinning globe with a wave of New Years photos taken at the global time.

With EXIF 2.31 or XMP the time-zone fields are actually defined, so (in theory) we can have both. Unfortunately, the state of implementation is still horrible if I look at Adobe Lightroom and certain other programs.

Messing up the whole situation regarding the file (not EXIF or XMP) dates is the problem that it depends on which time-zone your computer is set to when you transfer the pictures, as this stage defines the time-zone for the files.

E.g. photo taken at local time 10:00+5h (cam set to local time, but without time-zone knowledge); computer is set to home time-zone 6:00+1h, photos file creation time would receive time-zone from computer, so 10:00+1h on import; then we change computer time zone to +5h, and our photo is suddenly from the future, at 14:00+5h. Adding to the confusion is the format 13:43:22+05:00 does not mean to add 5h, but one has to subtract them to get to UTC (they were added from UTC).

So what remains as a conclusion: Wait and see. Hopefully this will become obsolete with GPS time in all devices at some point, or at least programs will show and allow to alter time-zone offset. Until then, geosetter is still my best friend.

I find that this discussion is mostly a red herring. What is actually important for keeping originals and processed files in proper order it that the dates of the image file on the media correspond with the current date when the card is accessed in its customary way (card reader or USB cable) by the computer.

Some cameras offer a time zone setting: if they do, I use it. Cameras don't offer different times for EXIF data and file data, so the file dates determine what timezone convention I go with on my camera. This has the potential to be different between media read by card reader or USB cable, and the potential to be different for SDHC cards (≤ 32GB, FAT32 file system) and SDXC cards (> 32GB, Exfat file system) even on the same camera. So you better standardise on media type and access method if there is a difference.

So far, I've generally ended up using UTC for the last years. Everything else made too much trouble for file processing.