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

Question

I live in the UK and spend most of my time here, apart from a short trip abroad once or sometimes twice a year.

This Sunday just gone we switched from GMT to BST, so our clocks went forward one hour. I updated my camera clock to match the new time, which is something I do every time the clocks change but someone said to me that this was a bad idea and that I should just leave it on GMT/UTC all year around. I guess this is partly due to GPS tracking (although I would normally use my iPhone which automatically updates it's time, so I need to sync my camera with my phone before I begin ideally).

I like the idea of updating my camera so it's on local time wherever I am in the world, but of course there is always the possibility of forgetting to do this. In the summer we are off on Honeymoon and will be in several different time zones, so the question is should I just make an effort to remember to update my clock time as I go, should I just leave it on GMT/UTC or is there a better way?

I am genuinely interested in what other photographers do to tackle this issue, especially with regard to travel and spending a few days at a time in different time zones.

I would also like to know how people handle the metadata when posting images online as the metadata could indicate a photo was taken on a different day due to a time zone mismatch. Also when reviewing photos I think it is often useful to know the times they were taken, especially with regard to sunset and sunrise, so knowing the accurate time can be important. Do you just have to manually work it out or is there considered to be a 'best practice' approach to dealing with this.

Very much looking forward to reading your responses.

Answer 1

I like to have date and times on photos reflect local times and date at the location. Unlike another respondent, I like to be able to search for a photo taken "at about 3pm on the Thursday afternoon when I was in Xian" and, while there are other ways of cataloguing and ordering, being able to search on local date and time is a bonus.

Travel from NZ involves long international flights (8-12 hours typical range unless going to Europe.)

I (try to remember to) change the camera date on the flight and change my wristwatch at the same time and take a before and after photo of the watch sequentially so I have a visual reference to the actual time of change in the photo stream.

Outbound from NZ the camera steps back in time so some photos will be out of time/date order. Making the change early in the flight minimises the impact if I care. e.g. China is 5 hours behind NZ and is ~ 8-10-12 hours flight time (Hong-Kong / Shanghai / Beijing) depending also on route so the time impact on photo date-sort order is usually minimal.

In the past I used to assign a long file name prefix based on properly time ordered date. Effectively YY MM DD HH SS in compressed form. It was useful but not so much so that I kept it going.

---

Added October 2022 - 10.5 years on:

For many years now I have used file names of form

      DSC09906`40121001`.JPG

This comes from camera card directory 401, year xxx2, October 1st.
This name is generated by XXCOPY as files are loaded from the camera card to memory, with the A attribute bit being reset on the camera card in the process. This has proved of immense value when processing and searching for files. I space folder numbers on different cards in several cameras in use by say 150 apart initially so that even photos taken on the same date with different camera can be readily distinguished.

The camera card is assigned as drive A:, then The current directory is set to the files destination desired. Then I run:

           xxcopy /bu /sx /m /nx0 %1:\dcim\*.j* a:\

for jpg fpgs plus RAW Video and Other).
/sx adds the folder - date suffix to the filename.

This works superbly.

Note that with the death of its owner a few years ago, XXCOPY has been made public domain.

---

Related:

Fixing corrupted file date & time: Due to Microsoft's cavalier handling of file date & time format when copying from cameras to hard drives you can find time offset by 12 hours and date by one day or both, on occasion. Confusing day and month is another sometime Microsoft speciality due to NZ using ddmmyy format as opposed to the usual US mmddyy format. Use of an EXIF to file date-time copying program fixes this. I use the excellent free jhead program to do this. Running jhead -ft *%1*.jpg in a [gasp!] DOS batch file will correct the date time to that shown in the EXIF for all files in a "folder". I believe that Microsoft Powertoys synch manager does this too but I have never tried it.

Travelling backup: I use the venerable and marvellous XXCOPY to incrementally copy in files from camera card to a netbook. When in tourist mode I carry the netbook everywhere and may download from camera card several times during the day. [Just because you are excessively paranoid about data loss it doesn't mean your cards won't fail :-)]. When XXCOPYing I change the archive attribute bit in the process, so that uncopied files can be identified, thus allowing an only-new files download incrementally AND leaving a backup copy on the camera card. I then copy from netbook to portable hard drive (possibly also during he day) and only then, if required, delete files on camera card. [On one journey I lost two of my 3 copies of photos (vanished with no clues, probably stolen) and still lost no photos.

---

XXCOPY code.
The following simple batch files has proved so useful for a decade or few that I offer it here 'warts and all'. I use a 2001 (!) version of XXCOPY for various reasons. Newer versions may or may not behave identially.

By (manually) ensuring camera cards have non overlapping date based folder numbers (xyz) the xxcopy suffixes xyzymmdd to each copied file and so allows folders with otherwise apparently identical file numbers to be distinguished - occasionally this saves files which may otherwise be overwritten or not copied. As the folder ID also includes a date time spamp it allows ALL my files to be unique when using multiple camera cards and multiple cameras - even if I swap cards between cameras during a 'shoot'.

It has done very well for me. It transfers all uncopied files from camera card incrementally, clears the attribute bit on the source (and destination) and appends folder ID and date-time stamp to the copied file name.

/SX - flatten subdirectories - add xyzymmdd before suffix.
/M - copy if A bit set, reset A bit.

SOME (very few) cameras only do NOT set the A bit for new video files. DO CHECK.
All cameras I have so far encountered do so for JPG and RAW files.

---

@echo off

rem Usage: SUCK DRIVE
rem Inputs Files from DRIVE with Attribute_bit_set to current directory

rem A: is copying target
rem This program is called with current dir = copying target
SUBST A: /D
SUBST A: .

rem %1 is source target drive
if not exist %1:\DCIM goto NoDrive

• rem Others MAY not want.
  rem Clear attribute bit for files in unwanted %1:\avfinfo
  attrib %1:\avf_info
  echo .
  attrib %1:\AVF_info*.* -h
  attrib %1:\AVF_info*.* -a
  attrib %1:\avf_info

xxcopy /bu /sx /m /nx0 %1:\dcim*.j* a:\

; Any files in DCIM not copied are deemed RAW.
md a:\Raw
xxcopy /bu /sx /m /nx0 %1:\dcim*.* a:\RAW

md a:\Video
xxcopy /bu /sx /m /nx0 %1:\MP_Root*.* a:\Video

rem ALL files on source with attrib still set are now copied.
md a:\Other
xxcopy /bu /sx /m /nx0 %1:*.* a:\Other

goto endit

:NoDrive
echo No drive with %1:\DCIM directory found
goto endit

:endit

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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!

Answer 7

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%.

Answer 8

I understand this is primarily an old thread but I think there is a newer issue, or perhaps I'm missing an obvious solution,

I travel a lot, and there are two priorities for my pictures:

(1) I want to organize my pictures by the local time where they were taken. Not only do I want to divide them logically into days, but when I want to find a picture taken at noon, I want to look for 12 o'clock.

(2) I need to synchronize the time on all my pictures, and video, from all 3 of my cameras (each have their advantage but typically I have a full frame, point and shoot, and phone).

Not sure why more people don't mention this, but for whatever reason, my MP4 video files, which have an internal UTC time, ALWAYS get translated to local time when transferring to Windows. Strangely, while it's the correct original local time on the SD card, when it gets transferred to the Windows PC, whether by the vendors app or File Explorer, the file time gets changed to the local PC time. No such translation is done for the JPG/Raw image files as they don't have UTC times (at least mine don't). So Video and image files time stamps end up out of sync. Not sure why I didn't notice this before as it's happened across 4 cameras and 2 different versions of Windows.

I've noticed some comments on the web claiming this is the camera vendors fault, but it's not. If anything, I think it's a Windows problem for not using the "Created" time from the SD file, or giving users the option (which is a complexity I'm sure they want to avoid).

In the meantime, I use a utility app to adjust the video files time stamp back to the original local time so they're synchronized with the images. I'd be interested in any alternate solutions.

Answer 9

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.

Answer 10

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.

Answer 11

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.